From clickable prototype to production in six weeks

A reinsurance client had a clickable prototype. It showed underwriters what the product should do: take in a submission, pull the data out of its documents, check it against the underwriting rules and produce a quote. Behind it there was no backend, no database and no infrastructure, and the finished platform had to run inside the client’s private Azure network, reachable only through locked-down remote desktops.

About six weeks after the first commit, it was running there in production. The team that joined later still builds on the same foundation, and after handover they made a major change to how much risk the platform will underwrite in a week, without rebuilding anything. The case study has the detail. This post is about what it took.

The gap a prototype hides

A prototype is the right way to agree what a product should do. It’s a poor guide to how much work is left, because everything that makes the product real is the part it doesn’t show:

• getting real submissions in, in whatever shape they actually arrive
• pulling data out of those documents reliably
• deciding what’s allowed, and recording who decided what and when
• running all of it inside a network the client controls

Real data made the gap obvious. A typical submission listed a couple of dozen locations. The largest listed nearly 14,000. A prototype built around the typical case looks finished until the largest one arrives.

The decisions that made six weeks possible

The speed didn’t come from coding agents on their own. OES used agents for much of the build, but the time was saved by settling the structural questions in the first fortnight, before anyone could argue about them later:

• One repository, with clear parts. A web app, a background worker, and separate packages for the business rules, the database and the domain types.
• Business rules in their own package. The app asks the rules what’s allowed. It doesn’t contain them. This is the decision that later let the client change underwriting capacity in a week. More on that change.
• Clear ownership of data. Each table has one part of the code that is allowed to write to it.
• Limits on the agents. What a coding agent may and may not touch, enforced by checks that fail the build rather than by a document nobody rereads.

In my experience these are the calls that are cheap in week two and expensive in month six. Made early, they cost almost nothing. Made late, they mean a rewrite.

Built to be handed over

The infrastructure was written from scratch as code, and the first deploy went straight into the client’s own Azure environment, behind their VPN. The infrastructure code matches what’s running, so the client can operate it without OES.

When the client’s team joined from late June, they were building on a structure that already said no to the wrong things. OES also set up the end-to-end test infrastructure, with stable test IDs and a guide the client’s external test team could work from.

Is your prototype in the same place?

Signs you’re closer to the start than the prototype suggests:

• the demo runs on sample data, and nobody has tried the largest real case
• the business rules live inside the screens, wherever they were needed first
• nobody has decided where the product will run, or who will operate it
• the plan for production is the prototype with a database added

Questions worth settling before the build starts:

1. Where do the business rules live, and who can change them?
2. Which part of the code owns each piece of data?
3. Will it run in your environment, under your control?
4. When a team joins, what stops the structure drifting?

What the client got

• Production in about six weeks, inside their own network.
• A foundation the team that joined still builds on, with no rewrite.
• Big commercial changes handled as rules and configuration work.

Have a prototype that needs to become a product? Let’s talk.