The best architecture decision makes the next big change boring

In one week, the team running a reinsurance underwriting platform I built made a major change to how much risk it will underwrite.

I wasn’t involved. By then the client had taken over the repository. That’s the point.

Nothing was rebuilt. It was a rules and configuration change.

One early decision

Early on, I put every underwriting rule in its own package: limits, layers, capacity, 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 on a clickable prototype against the clock, the tempting thing is to put the limit where you need it, in the quote screen, and move on.

Where the change landed

Look at where the change actually went:

• the new limits in the rules package
• database migrations in the database package
• the new types in the domain package
• the web app only displays the result, through the rules package’s public API

No route learned anything new about underwriting. No component grew an if about limits.

Why it stayed that way

Putting rules in a package is a decision. Keeping them there, with a team and coding agents writing code every day, is a different problem.

The boundary checks I left behind are why. They still gate every production deploy, and they fail the build if domain logic turns up in a route. So the path of least resistance for the team, and for their agents, was the right one. More on those guardrails.

What a client gets from this

The best architecture decision is the one that makes the next big change boring. A commercial change the size of this one should be a week of rules and configuration work, not a quarter of rewriting.

If your product’s next big change looks like a rewrite, let’s talk.