Rescuing a Stalled Insurance Platform

The Brief

Two years late. Five times over budget. No credible date for going live.

The platform was a specialist insurance product — an instant quote-and-buy flow for integrative wellness and med spa cover, backed by a Lloyd’s of London syndicate. The promise to the customer was a quote in minutes rather than the days or weeks a traditional broker would take. The promise to the business was a regulated, end-to-end digital channel that could underwrite, bind, and collect premium without a human in the middle for the simple cases. Lloyd’s capacity was already in place. Branding was done. There was a real product worth saving.

What was missing was not vision. It was delivery. Two years of build had not produced a launchable platform, and there was no honest answer to the question of when it would. The founder was running out of patience, runway, and reasonable explanations for the people who had backed the company.

KnowCode was not asked to design something new. The job was to step into a running build that had stopped progressing, decide what was salvageable, decide what had to change, and get the platform live and earning — without making the next six months look like the previous twenty-four.

What Was Actually Wrong

The diagnosis was unusual. The scope was fine — the product the team was trying to build was the right product, sized roughly correctly for a launchable v1. The failure was in the three layers underneath: the people building it, the way they were organised, and the platform they had built so far. Three scenes from the first weeks made the picture clear.

The forty-five minute call. Every morning began with a stand-up that ran most of an hour. The bulk of that hour was the product expert — the founder, with all the regulatory and commercial detail in their head — re-explaining the same insurance rules to the same developers for the Nth time. Domain knowledge that should have been written down once was being recreated by mouth every morning, and it was not sticking by the afternoon. The cost of that pattern is not measured in the lost hour. It is measured in the months of code written against a misremembered version of the rules.

The DocuSign clone. Several months of engineering had been spent building a bespoke electronic-signature flow inside the platform. The actual business problem — getting a particular declaration signed at the point of bind — could have been solved by amending the carrier’s existing document with a single new clause. No one upstream of the developers had asked the prior question: should we be building this at all? The answer was no, and a quarter of a year had been spent on the wrong answer.

The workflow engine in the browser. The platform’s core processing logic — eligibility, premium calculation, the rules that decided what kind of business could be quoted and at what price — ran as JavaScript in the buyer’s browser. There was no test harness, because the architecture made one impossible. There was no audit trail, because the place the calculation happened was outside the application’s server boundary. Anyone with developer tools open could read what they should not have been able to read, and every change to underwriting was a fingers-crossed deploy.

None of these were exotic problems. They were ordinary failures, of a kind that any sufficiently senior engineer would have caught the moment they were proposed. The reason they had survived for two years was that no one in the room had been senior enough to call them out and stand behind the call.

The Hard Call — A Smaller, More Expert Team

The first decision was the one nobody wants to make: the team had to get smaller, and the people who remained had to be more senior than the people leaving.

On a regulated insurance build running on Bubble, the real cost of a junior developer is not paid in salary. It is paid in months of architectural decisions that no one with the experience to question them is reviewing. A team that looks affordable on a spreadsheet stops being affordable the moment you account for the rework. The DocuSign clone, the client-side workflow engine, the morning re-explanations — each was the kind of mistake a senior engineer would have prevented in the conversation rather than caught after the code was written.

The mechanism for sorting senior from junior was simpler than a CV review or a coding test. Just ask the tough questions and see who can answer them. The tough questions in this build were not abstract — they were the decisions the platform had already been getting wrong. Why is the workflow engine running in the buyer’s browser? What happens to underwriting consistency the next time we change a rate? Why are we building an e-signature flow from scratch when the carrier already issues the document? The developers who could engage with those questions stayed. The ones who could not, did not.

People exited. The team shrank. What remained were developers who had built things before — regulated flows, payments, Bubble at the scale we were going to push it to, or all three. The work did not slow down. It sped up, because most of the work that had been happening was being undone.

Ship Every Wednesday

The single discipline that did the most work in the rescue was a release cadence.

Before, releases were ad-hoc. They happened when a developer decided something was ready, against a definition of done that lived nowhere in particular, into a stack with no real safety net. Every release was a small drama. The business had learned to expect each one to break something, and that expectation had become the relationship.

The new rule was simple. The platform ships once a week, on Wednesday. Whatever is ready ships. Whatever is not ready waits a week.

The cadence did two things, both load-bearing. It killed the “let’s try X” experimentation that had been quietly consuming half the team’s capacity — every proposed change now had to fit into a Wednesday, which meant either committing to a small enough shape that it would land, or deciding it was not worth doing. And it rebuilt trust. A few Wednesdays in a row where the release happened on Wednesday and nothing broke, and the business stopped dreading the words “deploy day.” The dev team’s word started to be worth what it said. The cadence was the social contract under everything else.

The Tech, Briefly

The architectural surgery that came alongside the team and process changes was not glamorous, and is not the point of this case study. But it is worth naming.

Core business logic moved off the client and into server-side workflows, where it could be unit-tested, audited, and inspected only by people who should be inspecting it. Underwriting rules stopped being something a buyer could read in their browser and started being something the platform owned. Architectural review became a named responsibility — one person owning the question “should we be building this at all?” before code was written against the answer. The DocuSign-clone scenario could not happen a second time, because somebody senior was now standing between the request and the keyboard.

Where It Sits Now

Six months from the start of the engagement, the platform was live and trading.

Med spa owners could go from a landing page to a bound policy in minutes, with premium flowing to the Lloyd’s carrier and a real underwriting decision — not a guess in a browser — behind every issued policy. The same platform that had been twenty-four months from going live was, half a year later, taking money on its own terms.

The build that follows looks nothing like the build that preceded it. It ships weekly. It has an owner for architecture and an owner for the timeline, and they are accountable to each other. The team is small enough to fit in a room and senior enough to disagree usefully when they do.

What I’d Do Again

Three lessons came out of the engagement that I would carry into any rescue of a stalled build.

Get live and earning first. The longer a platform is not in market, the less anyone — the team, the founder, the people who backed the company — remembers what it was supposed to do. The platform you ship in six months pays for the next six. The platform you spend two years perfecting in private pays for nothing, and quietly loses the argument about whether to keep going at all. Speed-to-revenue beats feature completeness, and it is not close.

Everyone on the project needs to understand the domain — not just the developers. Product, delivery, the people writing tickets, the people reviewing pull requests, the people approving what ships. If you have to teach the team how your business works, you have already lost four months — and at least one of those months will be spent building the wrong thing because the team learned the rules from a tired re-explanation rather than from having lived in the industry. This is more true now than it has ever been. AI writes the code. What it cannot do is decide whether the code should exist. The job of the people on the build has shifted from typing to supervising — and you cannot supervise a robot writing insurance logic if you do not yourself understand the insurance.

Make one person accountable for architecture and for dates. Not architecture or dates — both, with the same person standing behind both. Architectural decisions that ignore the calendar are theoretical. Timelines that ignore the architecture are fiction. When one person owns the trade-off, the build moves. When the two are split across people who do not have to face each other every Wednesday, the build drifts.

None of these are clever. That is the point. On a build that had been stuck for two years, the job was not to be clever. It was to have the experience to call out the simple things — and the seniority to stand behind those calls when they were unpopular. That is what was missing. That is what we brought. That is what got the platform live.