Why I Built Coding Capybaras: A Non-Tech Founder Story

Photo by Brian McGowan on Unsplash

I built Coding Capybaras because I was the customer who kept bouncing off everyone else's product. I'm a non-tech founder — I've run businesses, built commerce sites and operational systems for them, but I never came up through software engineering. Every SaaS boilerplate I tried assumed I had. This is the story of the wall I kept hitting, the moment AI coding tools changed what was possible for someone like me, and the months of building that turned my frustration into the product I launched this month.

The wall

The pattern repeated enough times that I can recite it from memory.

I'd have a SaaS idea. I'd do the responsible thing and buy a boilerplate instead of starting from scratch — ShipFast, Makerkit, one of the well-regarded ones. And to be clear, those are good products. They saved working engineers weeks of setup. That was exactly the problem: they were built for working engineers.

For me, the weekend would go like this. Clone the repo. Open the README. Hit the environment variable section and start a scavenger hunt across four dashboards for keys I didn't know how to name. Get to the Stripe section and meet the word "webhook" — which, I'd learn, meant configuring signature verification, handling replay attacks, and testing against events that only fire in production. Reach the Supabase setup and find a step that said something like "configure your RLS policies appropriately."

Appropriately. According to what?

I'd paste error messages into Claude. It would help, genuinely. But I was asking question forty-seven of a setup process designed for someone who didn't need to ask any. By Sunday night I'd have a half-configured app, no product, and the distinct feeling that the door to this industry had a sign on it I couldn't read.

The frustrating part wasn't the difficulty. I've learned hard things before; every founder has. The frustrating part was that none of this difficulty was my product. It was plumbing. Identical plumbing, in every SaaS ever shipped, that I was being asked to re-derive personally.

The moment it flipped

Sometime in 2025, the tools crossed a line. Claude Code could hold an entire codebase in context, plan a change across many files, run the tests, and fix its own mistakes. I wrote about what that workflow feels like in my Claude Code guide for non-developers, but the short version is: the bottleneck moved.

It used to be "can I write the code?" The answer for me was no, and that was the end of the conversation. Now the code gets written. The new bottleneck is "can I navigate the infrastructure?" Can I tell the agent what to build, in a codebase where the agent won't accidentally torch something important? Can I tell whether what it built is right?

Here's what I noticed when I went back to the boilerplates with Claude Code at my side: the tools had transformed, but the products hadn't. Boilerplates were still organized for humans who read code fluently. Configuration still lived in TypeScript files. The README still assumed the reader and the executor were the same person. When my AI assistant worked inside them, it had no guardrails — nothing told it "this file is load-bearing billing infrastructure" versus "this is marketing copy, go wild."

I had hit walls before and concluded the problem was me. This time I concluded the problem was the product. Nobody had built a boilerplate for the founder whose engineer is an AI.

So — with more confidence than evidence — I decided to build it.

What the build actually looked like

It took about six months, and the honest accounting looks like this:

| What I expected | What was true | | --- | --- | | The code would be the hard part | The architecture decisions were the hard part | | AI would slow down on complex features | AI slowed down on ambiguous instructions | | I'd need to learn to read code | I needed to learn to read plans and ask better questions | | The product was a codebase | The product was a guided path through infrastructure |

The biggest design decision came out of my own failure pattern. Every time an AI assistant had mangled a project of mine, it was because nothing distinguished "safe to modify" from "do not touch." So Coding Capybaras got three hard regions: the platform (auth, billing, email — locked plumbing), the website (marketing, yours to change), and the product (your actual app, yours to build). Every region carries rule files that tell an AI assistant exactly what it's standing in. It's the difference between handing a contractor your house keys and handing them keys plus a note about which walls hold up the roof.

The second decision: configuration through an admin GUI, not code. Pricing, branding, email templates, feature flags — all editable from the browser. Because the moment I watched myself ask Claude to "change the primary color in the config file," I realized I'd recreated the exact dependency I was trying to delete.

The third: the integration marketplace, with copy-paste AI prompts for wiring in tools like Sentry and PostHog. Not documentation about the integration — a prompt that does it.

My working rhythm with Claude settled into something I didn't expect. Early on, I treated it like a vending machine: put in a request, get out code, hope for the best. That failed in instructive ways. The sessions that worked were the ones where I made it explain the plan before executing, where I asked "what could go wrong with this approach" before accepting it, and where I made myself describe the why behind a feature, not just the what. The quality of what I shipped tracked the quality of my questions almost perfectly. Six months in, I understand more about software architecture than I ever expected to — not because I set out to learn it, but because reviewing a thousand plans in plain English turns out to be an education.

And what almost broke me wasn't any single feature. It was the dogfood rule I set on day one: codingcapybaras.com itself runs on the boilerplate. Same code anyone downloads. Which meant every shortcut I considered shipping, I would personally have to live with. There was a stretch — rebuilding the Stripe webhook handler for the third time, because "it works" and "a non-developer can trust it unattended" are different standards — where the temptation to quietly lower the bar was overwhelming. The dogfood rule is the only reason I didn't. I couldn't hide the product's weaknesses from its most demanding user, because that user was me.

Why capybaras

People ask, so: capybaras are famously calm in absurd situations. They sit in hot springs while monkeys climb on their heads. That is, roughly, the energy a first-time founder needs at 11pm when Stripe says signature verification failed and the launch is in four days.

It started as a working name and survived because it kept being true. The brand promise isn't "this is easy." It's "this is survivable, and you can stay calm, because the path is marked."

What launch taught me

I launched on Product Hunt on June 1, and the full retrospective is its own post. But the launch-day lesson that belongs in the origin story is this one:

The thing people responded to wasn't the feature list. Plenty of boilerplates have longer feature lists — my own honest comparison says so in a table. What resonated was the position: built for the founder whose engineer is an AI. The non-tech founders who found it didn't ask "does it have feature X." They asked "will I actually get to the end of the setup this time?"

That's the question I spent six months building an answer to. The guided journey — Supabase, Stripe, Resend, deploy, step by step with the AI prompts inline — exists because I needed to get to the end of the setup. Every design decision in the product traces back to some specific Sunday night where I didn't.

There was a quieter lesson in the launch, too. I'd assumed that being a non-tech founder was the thing to downplay — that credibility meant sounding like an engineer. The opposite turned out to be true. The most useful thing I brought to this product was an unfakeable memory of what it's like to not know. A working engineer building a boilerplate can't see the step that says "configure your policies appropriately" the way I see it, because to them it isn't a wall — it's a sentence. My entire product advantage is that I remember every wall.

I don't know yet whether Coding Capybaras becomes a big business. I know the free tier ships the complete codebase, because the wall I kept hitting should not have a toll booth in front of it. And I know the $97 Pro tier exists because I believe the ongoing work — updates, integrations, the stuff that compounds — is worth paying for once, not renting forever.

Frequently asked questions

Can a non-technical founder really ship a SaaS in 2026?

Yes — the constraint has moved. AI coding tools like Claude Code and Cursor now write production-grade code from plain-English instructions. The remaining hard parts are infrastructure navigation and knowing what to ask for, which is exactly what a guided boilerplate is for.

What does "non-tech founder" actually mean here?

In my case: someone who has built and run real businesses and systems, but never worked as a software engineer. I can follow technical reasoning and learn vocabulary fast. I cannot sit down and write a webhook handler from memory — and with current tools, I don't need to.

Why build a new boilerplate instead of contributing to an existing one?

The existing boilerplates are built for developers, and that's a structural choice, not a missing feature. Region architecture, GUI configuration, AI rule files, and prompt-based integrations had to be foundational decisions. Retrofitting them onto a developer-first codebase would have produced a worse version of both products.

Is the free tier actually the full product?

Yes. The complete codebase that runs codingcapybaras.com is what you download, and you can launch a real, paying SaaS on it. Pro ($97 one-time) adds attribution removal, ongoing updates, and a growing feature set.

What was the single hardest part of the build?

Holding the quality bar on infrastructure I'd never be able to fully audit myself. The fix was process, not heroics: dogfooding the product as its own production site, insisting on tests the AI runs against every change, and rebuilding anything I couldn't explain back in plain English.

Where this goes next

The origin story ends where the build-in-public story starts. I'm writing the journey here as it happens — the wins, the weeks that go sideways, and the running answer to whether a non-tech founder can operate a real SaaS, not just launch one. I write about this stuff weekly on the Coding Capybaras blog — and the boilerplate itself is free if you want to see exactly how I built it.