Skip to content
All writing

From clickable prototype to production in six weeks

A reinsurance underwriting platform went from a clickable prototype to running in the client’s private Azure network in about six weeks, with one engineer. The decisions that made that possible.

The brief was a clickable prototype. No backend, no database, no infrastructure.

About six weeks after the first commit, it was running in production inside the client’s private Azure network. For the first two months it was just me: 520 of the first 523 commits.

It’s a reinsurance underwriting platform: submission intake, document extraction, rules evaluation, quoting and audit history. There’s a case study on the work page. This post is about the decisions.

What a prototype doesn’t show you

A prototype shows what the product should do. The engineering is everything it doesn’t show you.

All I got was a clickable prototype, and I had to build out the whole thing. Getting submissions in. Pulling data out of the documents that actually arrive. Deciding what’s allowed. Producing a quote. Recording who did what and when. Running all of it inside a locked-down client network.

The calls a team would normally argue about

Working alone meant making the calls a team would normally argue about, early:

  • The monorepo structure. A web app, a background worker, and separate packages for rules, database and domain logic, set up in the second week.
  • Where the business rules live. In their own package. The app asks the rules what’s allowed; it doesn’t contain them. That one paid off later.
  • How the database is owned. Which code is allowed to write which tables.
  • What an agent is and isn’t allowed to touch.

I used coding agents for a lot of it. The speed came from deciding those things early, and then making the codebase enforce them with executable checks.

Getting it into the client’s network

The infrastructure was written from scratch in Terraform, and the first application deploy went into the client’s Azure Container Apps environment, which sits behind their VPN and remote desktops. The infrastructure code matches what’s deployed, so the client can run it themselves.

When the team joined

The team joined from late June. They were building on a structure that already said no to the wrong things.

I stayed the largest contributor on a five-person team: 55% of the commits and 54% of the test files. I also set up the end-to-end test infrastructure, with 281 test IDs and a guide the client’s external test team could work from.

What a client gets from this

  • Speed without a rewrite later. The structure that made the first six weeks fast is the same one the team still builds on.
  • An architecture a team can pick up, because its rules are enforced, not remembered.
  • Big changes as routine rules and configuration work.

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