Abstraction Engineering — Ramp Engineering
The key to some of Ramp’s early growth was our then opinionated product. The opinions represented both best practices for customers we were selling to, but also tradeoffs that we had made early in the product’s development. For example, all approval policies were conditionally determined solely based on amount. While it was possible to require one group of people for a request above $100 and a different for a request below, it was impossible to alter approvers based on department, accounting field, subsidiary, or any other field. This was a velocity tradeoff in the early days. However, in the fall of 2022, customers onboarding onto Ramp were breaking the assumptions made across the product early on and requesting significantly more configuration.
We solved this problem as most organizations would, by spinning up feature workstreams dedicated to solving specific versions of this problem: approvals, accounting field visibility, submission policies, custom expense notifications, and more. For certain, often larger customers, we went so far as to conditionalize logic based on the customer (or group of customers) in the codebase itself. Pavel Asparohouv (see his article on scaling bill pay) and I were tasked with improving approvals functionality for our nascent procurement product before we quickly realized that we were examining a specific case of an underlying problem. Continued iterative solutions would have led to increasing state complexity, operational difficulty, and features built on incorrect and imprecise abstractions.
