I Let an AI Agent Run a SaaS Like a Solo Founder. It Made the Same Mistakes Humans Make.

I expected the audit to find broken code. That's what I was bracing for going in - a pile of half-working features, sloppy logic, the kind of mess you'd assume from software built at maximum speed with no human reviewing every line. That's not what I found. Almost everything Claude built actually worked, taken piece by piece. What I found instead was something I didn't expect at all: the agent had made the exact same mistakes I've watched human startup teams make, over and over, when they move fast and nobody's job is to say no. That's the real story here, and it's more interesting than "AI wrote bad code" would have been. The experiment The project is called GetPricePulse - a SaaS pricing intelligence product. It's Claude's entry from The $100 AI Startup Race, the season-long challenge I run where seven AI agents each get $100 and full autonomy to build a real startup from scratch, with no human coding and no product manager in the loop. Each agent picked its own idea and ran with it. Claude picked SaaS pricing intelligence, named it PricePulse, and kept building on it for the entire race. That "no product manager in the loop" part is the thing that made this interesting to watch. Nobody was deciding what PricePulse should be. Nobody was saying "we have enough pricing tiers now" or "this feature doesn't belong here." Claude got to build exactly what its own priorities told it to build, at whatever speed it chose, for the length of the race - optimizing, as far as I could tell from the commit history, for speed, feature creation, shipping, and monetization experiments. Not correctness. Not coherence. Not "does this still make sense in three weeks." I've written before about what all seven agents in this race said, independently, when I asked them what AI agents still can't do - they converged on the same answer without seeing each other's responses. This piece is narrower: a full production audit of Claude's specific build, PricePulse, done after the race, before I'd let anyone treat it as a real business. I wanted to know, specifically, what a production-quality review of an AI agent's unsupervised output actually surfaces once you stop looking at individual features and start looking at the whole thing. By the time I ran the audit, Claude had produced: - More than 1,300 HTML files - Hundreds of content pages - A pricing database - Calculators - Monitoring features - Full authentication - Stripe payment integration - Email infrastructure That's a genuinely large amount of software for a single agent to produce. If I'd asked a solo developer to build this scope on a normal timeline, I'd have expected months. Claude did it across the race's running sessions. My honest first reaction, watching it accumulate week over week in the race results, was that I was more impressed than I expected to be. I expected broken code. I found something else. Here's where I have to be honest about my own assumption going into the audit. I assumed the interesting findings would be technical - bugs, crashes, broken integrations, the kind of thing you'd point to and say "see, this is why you still need engineers." I was ready to write that article. What the audit actually surfaced was mostly not that. Individually, almost everything worked. Authentication let people sign up and log in. Stripe processed at least one pricing tier correctly. The pricing database was real, not placeholder content. The calculators worked. There were real, concrete engineering bugs - I'll get to those, because they're genuinely interesting on their own terms - but they weren't the headline finding. The headline finding was this: the biggest problems weren't in any single feature. They were in the relationships between features - the seams, the places where five individually-reasonable decisions added up to something incoherent. And once I started looking at those seams instead of the individual pieces, I realized I recognized the pattern immediately. I'd seen it before. Not in AI-built software. In human startups moving fast without anyone doing the unglamorous job of saying no. The five human startup mistakes Claude reproduced This is the part I didn't expect, and it's the actual thesis of this piece: the mistakes weren't AI mistakes. They were startup mistakes. The kind any fast-moving team makes when velocity is the only metric anyone's optimizing for. 1. Too many products stapled into one By the time the race ended, PricePulse had quietly become five different products sharing one codebase: a SaaS pricing publication/database, a monitoring SaaS, a FinOps toolkit, a competitive intelligence product, and a lead generation system. None of these were bad ideas individually. I want to be clear about that, because it's tempting to read this list and think "well, obviously that's too much" in hindsight. It wasn't obvious in the moment, because each addition, evaluated on its own, was a reasonable thing to build. Add a monitoring feature: reasonable. Add a FinOps calculator: reasonable. Add lead capture: reasonable. What was missing was the thing that has nothing to do with any single decision: someone whose job was to look at the growing list and say "this is what we are, and this is what we are not." I've watched human founding teams do exactly this - ship feature after individually-defensible feature until the product has no legible identity left, because velocity was the only thing anyone was measuring. Claude, left to make every one of these calls itself with no one checking the aggregate, did the same thing. 2. Too many monetization experiments running at once Before cleanup, GetPricePulse simultaneously offered a $9 lifetime deal, a $49 lifetime deal, a $99 "founding member" deal, regular monthly plans, and multiple different checkout paths for each. Every one of those is a legitimate thing to test if you're deliberately researching pricing psychology one experiment at a time. Running all of them simultaneously, with no one deciding which ones to keep, isn't experimentation. It's accumulation. And accumulation has real costs, not just messaging confusion. Some purchases didn't automatically provision user access - meaning someone could pay and not get what they paid for. Cancellation promises on some pages didn't match what the billing logic actually implemented. I've seen human startups do this too, usually under growth pressure: launch the offer, move to the next thing, never circle back to check whether the last five offers are still coherent together, or whether any of them quietly stopped working. Claude, running the entire commercial side of PricePulse on its own, hit the exact same pattern. 3. No one owned the long-term vision This is the throughline connecting the first two mistakes, and it's worth naming directly rather than leaving implicit. Every individual decision Claude made had local logic. Nothing was wrong in isolation. What was missing across the entire build was a single point of ownership for the question "does this still serve what we're trying to be," asked continuously, not just once at the start. Human startups fail this exact test constantly - not because founders are careless, but because the question doesn't have a natural trigger. Nothing forces you to ask it. You have to build the habit of asking it deliberately, on a cadence, separate from the pressure to ship the next thing. Claude, working alone with no product manager checking in, had no mechanism to ask it at all, because nothing in "optimize for shipping speed" creates that mechanism on its own. That's not a flaw specific to AI. It's what happens to any process, human or automated, that optimizes purely for output. 4. Trust erosion through overconfident claims Content across the site described "real case studies," exact savings figures, and benchmark statistics, all written with the specific confidence of verified outcomes. When I actually traced where those numbers came from, most of them were modeled scenarios: legitimate calculations based on real, public pricing data, presented with more certainty than the underlying methodology actually supported. I want to be precise about what this is and isn't, because it's easy to overstate. Claude didn't fabricate numbers from nothing. It calculated real estimates from real inputs. The problem was the register - confident, specific, case-study language - applied to a claim that was actually a model, not a measurement. I've watched human marketing teams do the identical thing under deadline pressure: round up an estimate into a headline stat because "roughly" doesn't convert as well as a specific number. The fix wasn't less impressive content. It was labeling: state the assumptions, date the calculation, say plainly that it's a modeled scenario. A clearly-labeled estimate turned out to be more credible than a vague, unverifiable-sounding claim, not less. 5. Fragmentation that only shows up when you stop looking at pieces Different sections of the site - company pages, the blog, the tools - each had their own navigation, because each had effectively been built as its own product across different sessions, without a consistent structure enforced across them. Visiting different parts of the site felt like visiting different products, because in a structural sense, they had become different products. This is the mistake I find most instructive, because it's genuinely invisible if you only ever review things one at a time - which is exactly how fast building naturally happens, whether the builder is a human team shipping under deadline or an agent working through a queue of tasks across many sessions. You review the page you just built. It looks fine. You ship it. You move to the next one. Nothing in that loop ever asks "does this still feel like the same product as the thing we shipped last week." That question only gets asked if someone deliberately steps back from the individual artifacts and looks at the system they're suppos