From click-through prototype to production in under two weeks

A telecoms reseller sells SIM plans under more than one brand. It had a click-through prototype of the sign-up journey that looked finished: pick a plan, enter your details, sign up under whichever brand you came in through. It had no real data behind it, no infrastructure and no tests, and the business wanted to start selling.

About ten days after work started, it was in production on AWS. It has taken real customer orders since July. The case study has the detail. This post is about what made a launch that fast safe, and what it still missed.

A prototype that looks finished

The risk with a convincing prototype is that everyone, including the client, believes it is nearly done. Behind the screens of this one were tens of thousands of lines of made-up data. Every plan, order and customer came from a file, not from anything that could take money or create a SIM order.

So the first job was making it real: replacing the mock data with a real database and real services, and putting production on AWS, with the email, encryption and routing each brand’s domain needed.

What had to be true before launch

Going fast is only useful if the thing stays up once people use it. Before launch, OES put in the basics that stop a quick launch turning into a fragile one:

Production can’t be seeded with test data. A guard blocks it, so a mistake in a deploy can’t fill a live system with fake customers.
There is a runbook. Someone other than the person who built it can operate it.
Infrastructure is code. When the production environment went down during the build, from a database connection and authentication setting, it was fixed the same day. The fix went into the infrastructure code and was written up as an incident, so it can’t quietly come back.

The rest followed in the weeks after launch. Tests went from none to well over a hundred, on the server and end to end. Known dependency vulnerabilities went from nine to zero, with a playbook for keeping them there. And the architecture checks from an earlier project now run on every pull request, so new code follows the same rules.

What launch still caught

In the first week of real orders, customers weren’t getting confirmation emails. The orders were fine; the customers just had no idea. Nothing in the launch checks had looked for it, and it should have been caught before a real customer placed an order.

OES built branded confirmation emails and separate operations emails, made sending retry safely without duplicates, and backfilled the confirmations for the orders that had missed them.

The lesson is about where to look, not how fast to go. A fast launch needs someone watching the first real orders end to end, including everything that happens after the customer presses the button.

When the client then asked for a way to remove orders and sign-up journeys without losing the record, that shipped the same day.

Before you launch yours

If your prototype has a launch date, check these first:

Is any of the data still fake? Including the parts nobody clicks on in a demo.
Can production be filled with test data by accident?
Could someone else run it tomorrow? A runbook, and infrastructure that exists as code, not as one person’s memory.
Has anyone followed a real customer from sign-up to every email they should receive?
Who is watching the first week of real use?

What the client got

A product customers could buy from, in production in about ten days.
The operational basics done properly: tests, security, a runbook and infrastructure as code.
A launch gap found in the first week, fixed and backfilled.

Got a prototype and a date? Let’s talk.