Shipping a SaaS in 6 Months: What I'd Redo | Coding Capybaras

Photo by Pascal Debrunner on Unsplash

Shipping a SaaS took me six months, and if I did it again I could probably do it in three — not because I'd write faster, but because I wasted most of the lost time on two specific mistakes: building before I'd decided the architecture, and treating my AI assistant like a vending machine instead of a collaborator. This is the honest accounting. Where the months actually went, which weeks I'd hand back, and the handful of decisions that were worth every day they cost. I'm a non-tech founder, so this is a founder's retrospective, not an engineer's.

TL;DR

• The build took ~26 weeks; the single biggest time sink was the Stripe billing layer, which I rebuilt three times.
• The weeks I'd redo were lost to building before deciding the architecture — not to writing code.
• The decisions that paid off: hard region boundaries, GUI-based config, and dogfooding the product as its own production site.
• If I started over, I'd timebox the first version hard, write the plan before the code, and resist scope creep until I had real users.

Where the six months actually went

I kept a rough log, so I can tell you where the time went instead of guessing. The headline: there was no single dramatic month. The six months were a steady accumulation, with one phase — billing — eating far more than its share.

The numbers that surprised me: architecture and region design took only three weeks of building, but the thinking behind it was spread across the whole project. And the Stripe billing layer — webhooks, signature verification, the subscription state machine — took four weeks because I built it, broke it, and rebuilt it three separate times. I wrote up the specific traps in Stripe webhook hell, but the meta-lesson is the one that matters here: the part I most underestimated was the part I understood least.

Everything else was roughly proportional to what I expected. Auth and billing core was the longest single block at five weeks because it's the load-bearing plumbing — get it wrong and nothing above it is trustworthy. The admin config GUI, the marketplace, and the guided onboarding journey each took about three weeks. Marketing site and launch prep took another three.

What's not on the chart is the thing that actually slowed me down most: the gaps between phases where I stopped to redo a decision I should have made up front. Those gaps don't show as a labeled bar. They show as a project that took six months instead of three.

The mistake that cost the most: building before deciding

The expensive weeks weren't spent writing code. They were spent un-writing it.

Early on, I'd get an idea, describe it to Claude Code, and start building immediately. It felt productive. Code appeared. Features worked. Then a week later I'd realize the feature assumed a structure I hadn't actually committed to, and I'd have to tear it out and redo it once the real shape became clear.

The clearest example was configuration. My first instinct was to put pricing, branding, and email settings in TypeScript config files — that's how the boilerplates I'd used did it. I built a chunk of the product on that assumption. Then I caught myself asking Claude to "edit the config file to change the primary color," and realized I'd recreated the exact dependency on code-editing I was building this product to eliminate. So I ripped it out and rebuilt configuration as an admin GUI. The right call — but a week I'd have saved by deciding first.

This is a known failure mode, not a personal one. The indie hacker community has written about it for years: scope creep and building-before-validating are two of the most common reasons solo projects miss their timelines. What's specific to building with AI is that the tools make it worse, not better, if you're undisciplined. When code is cheap to generate, the temptation to start generating before you've thought is enormous. The cost just moves downstream, to the rebuild.

If I started over, the first week would be nothing but decisions written down in plain English. Region boundaries. Where configuration lives. What the billing state machine looks like. Not code — decisions. I'd treat the plan as the deliverable for week one, and I'd let Claude pressure-test it before a single file got written.

The mistake that cost the second-most: treating AI like a vending machine

My early sessions with Claude Code followed a pattern I'm slightly embarrassed by now. I'd type a request, get code back, skim it, and move on. Request in, code out. Vending machine.

That works for trivial changes and fails badly for anything load-bearing. The billing layer is the scar. I asked for "Stripe subscription handling," got something that looked right, and shipped it into the project without making the AI explain what it had built or what would happen when a webhook arrived twice. It took two more rebuilds before I changed my own behavior instead of blaming the output.

The shift that fixed it: I started making Claude explain the plan before executing, and I started asking "what could go wrong with this approach" before accepting anything. I also forced myself to describe the why behind each feature, not just the what. The quality of what I shipped tracked the quality of my questions almost exactly. I went deeper on this in my post on reading AI output when you don't speak code, but the short version is that a non-tech founder's leverage isn't writing code — it's interrogating plans.

There's a confidence trap here that's worth naming. Because the code looks authoritative, you assume it's correct, and you skip the step where you'd otherwise ask a dumb question. The dumb questions were where all my best catches came from. I caught a webhook that didn't verify signatures, a config value that was hardcoded, and a migration that would have broken on existing rows — all by asking something I was slightly embarrassed to ask.

What I'd keep exactly as it was

Not everything was a detour. Three decisions were worth every day they cost, and I'd make them again on day one.

The first is the hard region split. Coding Capybaras has three regions — platform, website, and product — with rule files in each telling an AI assistant what it's allowed to touch. This came directly out of my failure pattern: every time an AI had mangled a project of mine, it was because nothing distinguished "safe to modify" from "do not touch." Building those boundaries cost time up front and saved far more later, because I could let an agent work in the website region without worrying it would wander into billing.

The second is dogfooding. codingcapybaras.com runs on the boilerplate — the same code anyone downloads. This was the rule that almost broke me, because it meant I couldn't hide a single shortcut from the product's most demanding user, who was me. But it's also the reason the product is trustworthy. I told the fuller version of that story in the origin story.

The third is GUI configuration, the thing I rebuilt after my config-file detour. Once it existed, it was obviously correct, and it's one of the features non-tech founders respond to most.

If I started over: the three-month plan

Here's the version of this project I'd run today, knowing what I know.

Week one is decisions only. Architecture, region boundaries, where config lives, the billing model — all written down, all pressure-tested with Claude before any code. No building.

Weeks two through six are a hard-timeboxed first version: auth, billing, and a single working product surface, dogfooded from day one. The discipline I'd impose is the one the indie community keeps recommending and I keep relearning — resist adding features until real users ask. The most successful solo founders launch imperfect products quickly and improve based on feedback, and I built too much before anyone had touched it.

Weeks seven through ten are the differentiators — the admin GUI, the marketplace, the guided journey — but only after the core is solid. And the back half is launch prep, which I'd start earlier than I did. I covered the launch mechanics in my Product Hunt playbook; the lesson that belongs here is that launch is a phase, not a day, and pretending otherwise compresses it into a panic.

Three months is plausible because most of my lost six-month time was rework, not work. Decide first, interrogate the plans, resist scope creep, and the calendar shrinks.

Frequently asked questions

How long does it really take a non-tech founder to ship a SaaS?

In my case, six months part-time — but I estimate three is achievable if you avoid the rework I didn't. Industry-wise, most indie hackers take more than a month just to reach a first MVP, and the path to meaningful revenue is measured in many months, not weeks. Anyone promising a weekend is selling something.

What took the most time?

The billing layer, by a wide margin. Stripe webhooks, signature verification, and subscription state handling took four weeks because I rebuilt them three times. Billing is where "it works" and "a non-developer can trust it unattended" are genuinely different standards.

Did AI coding tools actually make it faster?

Yes, but only once I used them well. Used like a vending machine — request in, code out, no review — they let me build the wrong thing faster. Used as a collaborator I interrogated, they were a genuine multiplier. The bottleneck for a non-tech founder isn't typing code; it's deciding what to build and verifying what you got.

What's the one thing you'd change?

Spend the first week deciding the architecture in writing before building anything. Almost all of my lost time was tearing out work that assumed a structure I hadn't actually committed to. Decisions are cheap; rebuilds are expensive.

Is six months normal for a solo SaaS?

It's well within the normal range for a substantial product built part-time, especially a boilerplate that has to be trustworthy for other people. A narrow, single-feature tool can ship much faster. The more your product has to be reliable infrastructure, the more the timeline stretches.

What this taught me

The headline lesson of six months is unglamorous: most of the time I lost, I lost to myself. Not to hard problems, not to AI limitations, not to bad luck — to building before I'd decided, and to skipping the questions that felt too basic to ask. The hard technical parts were hard, but they were finite. The self-inflicted rework was the part that stretched three months into six.

If you're a non-tech founder weighing whether you can do this, the honest answer is yes, with discipline you'll have to learn the slow way unless you borrow mine. Decide first. Interrogate the plans. Dogfood relentlessly. And accept that the calendar is longer than the gurus claim and shorter than your fear says.

I write the rest of this journey as it happens on the Coding Capybaras blog — the boilerplate itself is free if you want to see exactly how the six months turned out.