How we shipped 6 production products in 8 weeks

Six production platforms in eight weeks. That sentence sounds like a pitch deck, so let me unpack what it actually means before anyone accuses us of building landing pages.

The six products are ComplyOS (UK compliance OS), CyberShield (consumer scam-check), X-Eagle (courier platform), HushOS (tinnitus therapy), HeartLog (ambulatory BP), and BahiKhata (AI accountant). Each has a production database with row-level security, an authenticated app, payments wired (or a deliberate decision not to bill yet), a UK-region production deployment behind a real domain, and at least one paying or operating user. X-Eagle has run 47 real deliveries. ComplyOS has logged 2,122 real compliance checks. None of these are demos.

Here is how we did it without burning out, without a team, and without skipping the parts that matter.

The three things we stopped doing

Most software projects die in the same three places: over-scoping the MVP, hand-rolling every primitive, and waiting for a "real" launch moment. We cut all three.

We stopped asking "what could this product become?" and started asking "what is the smallest thing that, if it existed today, we would already use?" ComplyOS started as a single page that recorded driver walk-around checks for an operating UK transport company. That's it. One form. One database table. Three days of work. The pharmacy module, the sponsor-licence module, the care-home module — those all came later, when actual users in those industries asked for them.

We stopped writing auth flows from scratch. We stopped writing magic-link emails from scratch. We stopped wiring our own webhook signature verification. Auth, transactional email, payments — the boring infrastructure is solved, and reinventing it is how teams lose a month.

And we stopped pretending there is a launch day. Every product goes live the moment it has one real user. CyberShield's first scan was my mother-in-law pasting in a Royal Mail smishing text. That was launch. Everything after has been improvement.

The reuse pattern that does most of the work

Each product is its own repo, its own deployment, its own database. We are deliberately not building a "platform" or a "monorepo." We tried that. It slows you down, because every product wants to drift in a different direction and you spend your week reconciling abstractions instead of shipping features.

But there is a pattern library we copy across, by hand, every time we start a new product. Roughly:

• A src/lib/site.ts with brand constants, nav, footer links.
• A src/lib/supabase with two clients: server (service role, server-only) and browser (anon).
• A src/components/effects.tsx with reveal, glow, magnetic and kinetic primitives.
• A glass / mono-big / sec-num CSS vocabulary baked into globals.css.
• A /api/contact route with Zod validation, honeypot, in-memory rate limit, transactional-email fallback.
• A consent-gated Plausible script, a robots.ts, a sitemap.ts, a .well-known/security.txt.

Copying this scaffolding is a 30-minute job at the start of a new product. It is not a framework. It is muscle memory. The day we try to abstract it into a private npm package is the day we stop shipping.

Design the data model before you write a line

Almost every expensive rewrite we have seen started as a schema someone guessed at in week one. So we never open an editor first. The loop is always the same:

1. Sketch the data model in plain English in a markdown file.
2. Write the SQL migration + row-level security policies against that sketch.
3. Read every policy back. Reject any that grants more access than intended.
4. Write the route handlers + tests.
5. Run it locally. Break it on purpose. Fix what broke.
6. Commit small. Push small. Preview deployment per PR.

Steps 3 and 5 are the ones people skip, and they are the two that decide whether the product survives its first real user. A migration is cheap to change on day one and expensive on day ninety, so the sketch earns its half hour every single time.

Reading the diff is the job

If there is one habit that separates teams that ship safely from teams that ship and then scramble, it is treating the diff as the artefact. Every PR gets read line by line before merge. Not skimmed. Read. Code that compiles and passes tests can still introduce subtle policy holes, leaked PII in error messages, missing cleanup paths, or behaviour the user didn't ask for. Tests do not catch those. Looking does.

We use our own products to run our own businesses

This is the part that most studios can't replicate, and it's the unfair advantage.

X-Eagle is the dispatch platform for my actual courier company. Every driver login, every job, every cash drop, every walk-around check is real. ComplyOS sits on top of it, logging the compliance side. BahiKhata books the takings. CyberShield runs against our staff inboxes.

This means three things that compound:

1. Every bug is felt by us first. A regression in the driver app means our drivers can't work. A flaky webhook means our customers don't get a delivery confirmation. The feedback loop is hours, not weeks.
2. We never ship a feature nobody asked for. Every line of code traces back to something one of our companies needed yesterday. That's a brutal but useful filter.
3. We can show numbers, not screenshots. When we tell you ComplyOS has logged 2,122 checks, that's a SELECT count(*) against a production table, not a marketing claim.

What we didn't do

For honesty's sake, the things we deferred:

• Comprehensive test suites. Each product has smoke tests on critical paths (auth, payment, the one thing that, if broken, loses money). Nothing else. We will pay for this later. We know.
• Custom design systems. We use Tailwind, a small set of primitives in effects.tsx, and a brand colour palette. We don't have a Figma library. We don't want one yet.
• Native mobile. A cross-platform framework wraps the same web app into a Play Store / App Store binary. We are not writing two codebases.
• Internationalisation. Everything is en-GB. The day a customer in another locale signs a real contract, we'll build it. Not before.

The honest disclaimer

Shipping six products in eight weeks is possible. Shipping six good products in eight weeks is harder, and we are not pretending all six are equally polished. ComplyOS and X-Eagle are battle-tested. BahiKhata is in real-business use by us. CyberShield, HushOS, HeartLog have early users and rough edges. We are upfront about that on every product page.

The point of this note is not to brag about velocity. It is to argue that the gap between "I have an idea" and "real users are using it" should be measured in weeks, not quarters — and that a small set of disciplined defaults, applied without exception, closes that gap on its own.

If you want the boring details (RLS templates, auth flows, transactional-email wiring), they are in our research notes and we'll post more here as we cut new patterns out of new products.