The best architecture decision makes the next big change boring
After handover, a client’s own team raised their underwriting platform’s capacity by more than 130% in a week, without the original engineer and without a rebuild. The early decision that made it routine, and how to tell if your next change will be.
, updated , filed under architecture, sveltekit, monorepo, rules, delivery
For most founders, the worrying moment isn’t launch. It’s the first big commercial change after launch: a new pricing model, a new market, a limit the business has outgrown. If the product was built in a hurry, that change is where you find out the rules of the business are scattered through every screen, and that the only person who knows where is the engineer who built it.
A reinsurance underwriting platform OES built hit that moment in September. The business needed to raise how much risk the platform would underwrite, by more than 130%. The client’s own team made the change in a week. OES wasn’t involved; by then the client had taken over the repository. Nothing was rebuilt.
One early decision
Early in the build, OES put every underwriting rule in its own part of the product: limits, layers, capacity and checks. The app asks the rules what’s allowed. It doesn’t contain them.
At the time that looked like extra structure for a product with one client and a short deadline. Building from a clickable prototype against the clock, the tempting thing is to put a limit wherever it’s needed first, in the quote screen, and move on. It’s quicker that week, and it’s how a one-week change becomes a quarter of rework later.
Where the change landed
When the change came, it went exactly where the structure said it should:
- the new limits in the rules
- the data changes in the database layer
- the new shapes of data in the domain types
- the web app only displays the result, by asking the rules
No screen learned anything new about underwriting. That’s what made it a week of routine work for a team that didn’t design the system, rather than a project that needed its original engineer back.
Why it stayed that way
Putting rules in one place is a decision. Keeping them there, with a team and coding agents writing code every day, is a different problem.
The architecture checks OES left behind are why it held. They gate every production deploy and fail the build if business logic turns up in the wrong place, so the easiest path for the team, and for their agents, was the right one. More on those guardrails.
Will your next big change be boring?
Ask your team, or whoever built your product:
- If we changed our pricing or limits tomorrow, how many places in the code would change?
- Could our own team make that change without the original builder?
- What stops a quick fix putting a business rule back in a screen?
If the answers are “lots”, “probably not” and “nothing”, the next big change is a rewrite waiting to happen.
What the client got
- A major commercial change, more than 130% more capacity, delivered in a week.
- Made by their own team, without the engineer who built it.
- No rebuild, and no rules scattered through the product to find first.
If your product’s next big change looks like a rewrite, let’s talk.