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.

AI as a junior, not an oracle

We use Sifotech AI — our internal frontier-model engineering layer — the same way you'd use a fast, eager junior engineer with no memory between days. We never ask it to design the system. We ask it to implement the system we already designed.

The workflow looks like this:

1. Sketch the data model in plain English in a markdown file.
2. Ask the AI to write the SQL migration + RLS policies.
3. Read every line. Reject any policy that grants more access than I'd grant manually.
4. Ask the AI to write the route handlers + tests.
5. Read every line again. Run it locally. Break it on purpose.
6. Commit small. Push small. Preview deployment per PR.

The AI is brilliant at the boilerplate (migrations, types, form validators, MDX renderers, RSS generators) and terrible at the judgement calls (what data to expose, where to draw the auth boundary, when to say no to a feature). Pretending it is the other way around is how you ship a vulnerability.

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 by a human before merge. Not skimmed. Read. AI-generated code that compiles and passes tests can still introduce subtle policy holes, leaked PII in error messages, missing cleanup paths, or features the user didn't ask for. We catch those by looking.

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 AI plus a small set of disciplined defaults makes that gap close on its own, if you let it.

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.