Loading…
Ramp
Corporate card and spend management platform building innovative financial technology solutions for businesses.
- 50 posts summarised
- latest
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
From their blog
Latest articles
Cost Efficient Snowflake CI
Ramp’s data team used Snowflake CI checks that created a full duplicate production database for each pull request, causing rising warehouse costs and up to 30 minutes of developer idle time as pull-request volume and model count grew. They changed the process by storing dbt manifest.json artifacts in S3, using dbt’s state selector to build modified models, and generating an upstream-model list for cloning. A custom dbt macro uses Snowflake’s information schema to create zero-copy clones of required production tables in the pull-request database, preserving a single namespace for debugging instead of relying on defer across databases. The resulting CI command sequence builds and tests modified models plus direct downstream dependencies, and the post reports a dramatic, mostly sustained dip in the rolling seven-day average warehouse cost despite higher pull-request velocity.
Rate limiting with Redis
Rate limiting at Ramp must handle third-party API quotas, globally paced Celery tasks, and inbound API traffic limited by authenticated application identities rather than only mutable IP addresses. Celery’s per-worker controls were insufficient for global limits, while queue prefetching could let rate-limited tasks block workers and stall queues. The team created a general framework for comparing algorithms and evaluated fixed-window, sliding-window, leaky/token-bucket, and Generic Cell Rate Algorithm (GCRA) approaches. They selected GCRA for implementation simplicity and compute and memory efficiency, storing a theoretical arrival time in Redis and using a Redis lock to prevent races. The implementation also uses floating-point timestamps, Redis server time, key expiration, unit tests, and manual testing; it has been introduced gradually across the three use cases, with monitoring, while additional algorithms remain planned.
Faster Pull Request Merges
Ramp’s growing Python pytest suite took over 12 minutes, while pull requests could wait up to one to two hours between merge queueing and production. Previously, Kodiak kept pull requests in a merge queue, requiring each PR to be up-to-date with master and rerun the full suite after every merge. Removing that requirement exposed a failure mode: parallel branches could introduce Alembic migrations with multiple heads, making the database migration history invalid. Ramp instead added migrations/migration-hash.txt, a hash of migration filenames that creates merge conflicts between migration-changing PRs while leaving other PRs free to merge; the deploy pipeline still runs tests on master before deployment. This reduced average merge time from more than an hour to 12 minutes.
Faster Python Tests
The title, “Faster Python Tests,” identifies test speed as the intended subject. The accompanying material consists of HTML metadata, favicon and RSS declarations, a JavaScript bundle reference, analytics setup, and a notice that JavaScript is required to run the app. It does not state which Python test framework, execution bottleneck, configuration, code change, or measurement was involved. Consequently, no implementation approach, benchmark, performance figure, or conclusion about faster tests is provided in the available text. The only technical details exposed are the page’s JavaScript application shell and its Segment and Google Analytics initialization, neither of which explains how Python tests were accelerated.
Bootstrapping a UI component library
Ryu is a component library created at a small startup to separate design concerns from feature development and business logic while product and conventions continue changing. It mirrors Figma's design system through shared colors, sizes, fonts, line heights, media breakpoints, z-indices, and components such as inputs, buttons, tooltips, menus, tables, and drawers. The article argues for a hard boundary between the library and main codebase, using a separate repository and an npm package with documented interfaces, hand-crafted changelogs, versioned releases, and extensive TypeScript. It emphasizes resisting narrowly tailored settings, postponing unresolved use cases, and prioritizing adoption over completeness, including preventing new code from using legacy components without good reason. Building on mature existing components while simplifying their interfaces, the library aims to improve maintainability, consistency, accessibility, theming, contribution, and coordination across applications.
Lessons from my internship at Ramp
The author reflects on a three-month software engineering internship at Ramp from March to June, describing lessons about execution, company choice, and location. Ramp’s charge card appeared to be a commodity, but the author credits its bias for shipping quickly, technical and product strength, differentiated technology, and favorable capital secured through finance expertise with turning it into a distinctive product. Compared with more formal, lower-stakes internships, Ramp offered flexibility, mentorship, and exposure to a fast-growing organization, although its pace and limited documentation could be challenging. The experience also shaped the author’s view that working on large problems at such a company can magnify impact, while New York provided experiences and a tech community distinct from San Francisco’s.
Making big bets in business
The post argues that startups should pursue asymmetric outcomes: bets with potentially large upside and limited, manageable downside, rather than optimizing for average advice or minimizing every risk. Drawing on the founders’ experience building Paribus and Ramp, it applies this principle to choosing a problem space, hiring, vendors, product development, and fundraising. An outsized seed round enabled Ramp to pursue financial services despite high barriers to entry, while early hiring favored exceptional, fast-growing people over candidates who matched every competency checklist. It also recommends testing scrappy vendors, listening to customer problems rather than proposed solutions, and selecting reputable investors with clean terms. Ramp’s counterexample is credit risk: because revenue is about 1% of lending, a mistake can cost roughly 100 times its reward, so threatening risks should be isolated from bolder bets.
Engineering Principles at Ramp
Ramp documents seven engineering principles intended to codify how its teams build systems, make decisions, and collaborate as the company grows. The principles call for choosing technology according to each system’s context, moving aggressively on reversible decisions while treating durable interfaces cautiously, and aligning system models with customer concepts. They also favor opinionated product experiences, accepting duplication over a harmful abstraction while continuing to seek abstractions that reflect meaningful shared behavior. Rather than implementing requests literally, engineers investigate underlying needs, such as notifying a CFO instead of making approval a bottleneck, and break projects into small, independently prioritized chunks. These chunks can be owned by small teams called “pods,” while the principles remain adaptable rather than ironclad rules.
My summer at Ramp
My summer at Ramp recounts a three-month internship at the financial automation startup, following an introduction to its mission, growth, and product. During the placement, the author standardized physical-card shipping data, improved accounting workflows, handled profile-picture and UX work, and resolved production issues while improving endpoint and application performance. The main project, Filtering and Renaming GL, let Ramp administrators control accounting-option visibility by cardholder department and rename cryptic options within Ramp. The internship also provided observations about fintech opportunity, Ramp's rapid growth, transparency, ownership-driven culture, and the speed-quality trade-off described as product velocity. The author planned to continue at Ramp part-time while entering the third year of college.
Elixir at Ramp 🧪
Ramp engineer Pablo describes why Elixir suited several critical services, while arguing that technology choice is only one part of engineering success. He contrasts BEAM, Erlang’s virtual machine, and OTP’s abstractions for reliable, concurrent systems with the adoption and developer-experience advantages of Elixir, including familiar syntax, Mix, iex, hot code reloading, doctests, macros, and sigils. Immutability and aliased module calls are presented as safeguards against hidden state changes and circular-import problems in growing codebases, though the post also notes that Erlang and Elixir lag behind bolted-on type checkers. Ramp uses Elixir for its real-time Authorization engine and Risk analysis platform; the Authorization service is described as exceptionally stable and flexible for rapid feature development. The company’s largest backend remains Python, and the conclusion prioritizes sleep, trust, ownership, and psychological safety over any specific stack.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.