When I joined the studio as engineer number three, the promise was straightforward: custom software for mid-market clients, whatever shape the client needed. Over three years we shipped fifteen of them — SaaS backends, mobile companion apps, internal tooling, a web3 marketplace, an e-commerce platform. The projects looked unrelated on the surface. They weren't.
The first few builds were slow. We estimated eight weeks and spent twelve, every time. The usual culprits: auth re-invented from scratch, a new admin panel layout each round, a different state-shape for the same list-detail-edit flow. We were shipping bespoke furniture when the clients mostly wanted bespoke rooms.
Repetition is the asset
The turnaround started once we treated our own repetitions as the product. Auth became a module. The admin CRUD shell got codegen around a schema file. The React Native shell for field-sales clients was copied — not forked, copied — into every mobile project that followed. The first time we reused a module it saved three days. By the tenth project we were skipping entire two-week slices of the estimate.
"If you can't name the three projects this pattern came from, don't abstract it yet."
— A rule we wrote on a whiteboard and never took down
The trap on the other side is just as real: premature abstraction. We killed more than one shared helper that turned out to exist because two projects wanted almost-the-same thing, and every new client bent it further out of shape. The discipline was to let patterns cost us three times before we touched them, and then to extract them in the simplest form possible. Copy first, abstract later.
What actually compounded
Three things compounded more than the code itself: our estimation, our onboarding, and our boredom. By the last year, estimates landed within a few days of reality. New hires could ship against the template stack in their first week. And we got bored — which turned out to be the most useful signal of all. The boring project is the one where you're free to actually care about the interesting ten percent.
I don't think the lesson is "build a framework." Frameworks rot. The lesson is closer to: notice when you're writing the same thing twice, write it down, and treat your own past work as a library you're allowed to reach into. Most shops don't, which is why every project feels new and every estimate is a guess.