We Built 7 SaaS Products in 6 Months — Here Is What Broke First

I made a bet six months ago that I could ship seven real SaaS products in parallel using AI-augmented development and a small set of boring, repeatable infrastructure. Not landing pages — real products with auth, billing, databases, and users. As of April 2026, the portfolio is at various stages of ship: some live, some polishing, some frozen pending design partners. Here is an honest debrief on what broke first and how I would do it differently.

The first thing that broke was Vercel ghost states.

You push a deployment, the build passes, the URL returns 200s. You move on. Three days later a friend tries to sign up and nothing works because the new API route never actually made it into the production environment — the build cached an old step, or the env var only propagated to preview branches, or the Clerk middleware was scoped to a path that the deploy silently rewrote. I spent more weekends debugging Vercel state than I want to admit. Lesson: after every deployment that touches auth, billing, or database, run a smoke test as an actual unauthenticated user from a clean browser. Automate this. The logs will tell you nothing is wrong. The user flow will tell you everything is wrong.

The second thing that broke was Clerk and Supabase integration boundaries.

Clerk owns user identity. Supabase owns your data and its row-level security policies. Both of them want to be the source of truth for the current user's ID. If you do not decide up front how you are passing the Clerk user ID into Supabase — as a JWT claim, a header, or a custom RLS policy — you end up with 401 errors that only appear when you have more than one user. Single-tenant dev works. Multi-tenant production falls apart. Fix it early. I learned this twice before I wrote it into our internal scaffolding.

The third thing that broke was the Claude CLI pattern for multi-repo work.

I run Claude Code across seven product repos. Early on I used a single global instruction file and expected context to carry. It did not. Claude in repo A has no idea what conventions repo B is using. The fix was per-repo CLAUDE.md files with specifics — tech stack defaults, DO-NOT-TOUCH files, naming conventions, testing expectations. Combined with a single global CLAUDE.md for identity and working style, this gave me context-aware AI assistance across the portfolio without cross-contamination. If you are running agents across multiple projects, split your memory the way Claude's memory system splits it. Global is for the person. Local is for the project.

The fourth thing that broke was demo user seeding.

Every product needs a realistic demo mode. Investors, first customers, and founders kicking tires will churn in under five minutes if the app is empty on signup. Early on I hand-seeded demo data per product. That does not scale to seven. By product three I had built a reusable demo-seed pattern — a single script per product that populates a demo tenant with realistic data on first login. This is now the first infrastructure I stand up on any new product, before I write the happy path. An empty app is a dead app.

The fifth thing that broke was product-specific quality bars.

Every product had a tension between polish and momentum. The B2B product that serves financial advisors (EAS) needs enterprise-grade auth, audit logging, and legal disclaimers — Fortune 500 buyers literally cannot use a tool that logs them in via magic link. The consumer-adjacent product (APEX Terminal for retail traders) needs speed, visual polish, and forgiving error states, but can skip audit logs entirely. Applying the B2B bar to the consumer product slowed it down. Applying the consumer bar to the B2B product made it unsellable. The resolution was brutal: write the quality bar down for each product before you start shipping. What do you check in before merging? What is out of scope? Different per product. Decide once, then execute.

The sixth thing that broke was operational overhead.

Seven products means seven marketing sites, seven support inboxes, seven analytics dashboards, seven Stripe accounts, seven sets of customers asking different questions. The compounding is real. By month four I had lost visibility on which product was healthy and which was bleeding. The fix was a unified command center dashboard — one internal page showing signups, MRR, active users, error rates, and last-deploy time across every product. Five hours a week back. If you are running more than two products, build this on day one, not month five.

The seventh thing that broke was my own energy.

Parallel products means parallel contexts, and parallel contexts are exhausting in a way that single-product founders do not appreciate. Monday mornings doing APEX work, Monday afternoons doing Mahon work, and you are not "context switching" — you are paying a 30-minute reorientation tax between every block. I ended up blocking days to products: Monday for APEX, Tuesday for Mahon, Wednesday for Silver Owl client work, Thursday for EAS. Deep work requires 3+ hour blocks in a single context. The day-per-product rhythm was the only way to sustain velocity without burning out.

The eighth thing that broke, honestly, was the assumption that seven was the right number.

Would I do seven again? No. Three products is the right count. The economics are equivalent — the infrastructure pays for itself after the second product, so adding a third is almost free. The fourth through seventh products added stress without proportional learning. The reason I did seven was that I had a backlog of ideas waiting too long, and I wanted to clear the queue. That was a founder issue, not a portfolio strategy. If you are starting a multi-product agency today, pick three. Two you are confident in, one that feels risky but exciting. Ship those hard.

The meta-lesson from six months of this is that shipping is the only teacher. Planning taught me about 20% of what I learned. Shipping taught me 80%. The specific products matter less than the rep count. Do this seven times — or even three times — and you start seeing patterns that single-product founders never see: which infrastructure is actually reusable, which marketing channels work across verticals, which pricing models translate, which types of customers are always painful regardless of product.

The AI-augmented development was the enabling condition, but it was not the story. The story was infrastructure reuse, written specs, day-per-product discipline, and the willingness to ship things before they were perfect. The AI removed the tax on boilerplate. It did not remove the tax on judgment. That is still the bottleneck, and it is still the thing you have to earn.

If you are considering going multi-product: three products, shared infrastructure, written specs, day-blocks per product, and a smoke-test on every deploy. That is the playbook. Everything else is noise.