Break Predictably, Recover Fast

An engineering doctrine forged on hostile ground

Karim Atiyeh, co-founder of Ramp, describes an engineering doctrine he traces to his earlier company Paribus and carried into Ramp.¹ It inverts an instinct that most experienced engineers absorb at large companies: that the goal is to build a great system that will not break and will withstand the test of time.

Paribus was built on what Atiyeh calls a hostile, unstable foundation, namely the websites of retailers who did not want it there, changed their pages constantly, and were incentivized to make scraping harder over time, to the point that Amazon stopped emailing itemized receipts. On a foundation like that, he argues, "you're never going to really build the perfect system." So the doctrine reversed the usual aim: "You're better off building something quickly that will break in very predictable ways and that you are able to recover from incredibly quickly." Atiyeh grants the never-break posture its beauty; he considers it the wrong tool when the ground is moving underneath.

The split, not the slogan

The non-obvious half is that the lesson did not transfer to Ramp as "move fast and break things everywhere." It transferred as a deliberate two-speed architecture, with the product and engineering organization split along the boundary early. On one side sit the never-break systems, money movement and risk: "You need to build it right, make sure it doesn't break, and assume you're not going to have to innovate that much." These barely change; the work is to build them well once. On the other side sits everything else, from receipt-matching to forms to fonts, colors, and buttons: "If it works it's amazing; if it doesn't, it's whatever, no one's going to feel it." Atiyeh claims that "little parts of Ramp are breaking 10 times a day and we're fixing them 20 times a day and no one's noticing."

The split is the actual content of the idea. Reliability, in Atiyeh's framing, is not a uniform virtue to maximize everywhere. Scarce never-break engineering is spent on the rails where a failure is catastrophic and irreversible, and velocity is spent everywhere the downside of a failure is a shrug.

Breaking fast as a trust-builder

Atiyeh reports a counterintuitive payoff. With a skeptical early customer, visibly fixing a break quickly built more credibility than a product they never noticed: "I often find it a much better way to build credibility and trust if things break and you fix them very quickly, as opposed to if they just don't notice anything about the product." He treats a reported break as a personal challenge measured in how fast the team notices and how fast it fixes. In the strong form of the claim, breakage on the high-upside side becomes evidence of taking enough risk: "What's one great way to make sure you have no bugs? Don't ship anything. If you are solving for great outcome and great impact, you want things to be breaking."

Tensions

Atiyeh's own account names the failure mode. The split works only if the boundary is drawn honestly. A "break-fast" classification placed on something that is actually load-bearing, such as a silent data-corruption path that "no one notices," is how the doctrine turns into recklessness. The phrase "no one notices" does heavy work: a missed receipt match is invisible, but a subtly wrong classification at scale, on the order of 1 percent of 100,000 a day, may not be, and the doctrine assumes the failure distribution on the fast side is genuinely benign. The concept sits as a productive contrast to worst-case scenario first, which front-loads the catastrophe question on everything; Atiyeh's version restricts that discipline to the never-break rails and deliberately refuses it elsewhere.