13 Months Building a SaaS Alone With AI: What Actually Shipped
The seventh attempt is the one that stuck.
The feature was headers and footers on generated PDFs. Page numbers, logo placement, margins that hold up when the content runs long. It looks like a two-day ticket. It wasn’t. I built it, pushed it, reverted it. Built it again, reverted again. Six times. The seventh version shipped and it’s still running.
I’m opening with that because almost everything written about AI-assisted development leaves that part out. You get hype, or you get dismissal, and both usually come from someone who ran a demo on a to-do app for an afternoon. I did this for about 13 months on a live product with paying customers, and I kept the receipts. This post is the ledger — the numbers, the failures, and the places where I still had to be the human in the room.
Why I was the one writing the code
When I ran Pulse360, a B2B SaaS for financial advisors, I wasn’t the obvious person to be shipping code. I spent 20 years in wealth management as an advisor before founding it in 2019. And for years I ran distributed engineering teams across six countries — Argentina, Spain, London, India, Ukraine, Russia. My job was hiring engineers, not replacing them.
That background matters for one reason: I know what a real team’s velocity looks like. I’ve sat in the sprint planning. I know what “two weeks” means when four people say it.
When AI coding tools got genuinely usable, my engineering team didn’t want to adopt them. They saw the tools as a threat to their jobs. From where they were sitting, that was a rational read — I’m not going to pretend otherwise. But I still had a roadmap, customers waiting, and deals stalling on missing integrations. So I took the work on myself and started shipping.
What 171 days actually looked like
I worked this way for roughly 13 months. Partway through, I pulled hard numbers out of three production repositories — July 1 to December 19, 2025. That’s 171 days. Here’s what came out:
- 253 pull requests merged. 253 out of 253 — a 100% merge rate. All of them deployed to staging or production.
- ~670 commits.
- ~150,000 lines added, ~30,000 deleted. About 120,000 net.
- Average PR: 838 additions, 168 deletions.
- Rate: ~46 PRs and ~122 commits a month. The peak stretch was 20+ PRs in 19 days.
The big ones were genuinely big. The largest single PR was +25,331 / −1,851 lines — that was a release. Another was +8,736 for a standalone task system. Another was +7,501 for error reporting plus a UI overhaul. Tools were Claude Code, Cursor, and Roo Code.
None of this was prototypes. Every line of it went to a product that advisors logged into the next morning.
What that would have cost in team-months
Here’s where I have to be careful, because this is the number people quote and it’s the softest one on the page. It’s an estimate, not a measurement.
Based on managing teams that built comparable systems, I’d put this scope at 24 to 30 months for one senior developer, or 10 to 12 months for a team of three seniors. Against a single senior dev, that’s roughly a 4.4x to 5.5x multiplier.
I want to be blunt about what that number is not. It’s not “AI made me a 10x engineer.” It’s not evidence that developers are going away — I hit walls constantly that only a human could get past, and I’ll get to those. And a solo operator skips a lot of overhead a real team carries for good reasons: no handoffs, no coordination, no explaining context to someone who wasn’t in the customer call. Some of my multiplier is AI. Some of it is just being one person with the whole picture in my head.
What I’ll defend without hedging: the shipped artifacts. 253 PRs, all merged, all deployed, on a product with paying users.
The part nobody puts in the case study
The PDF header feature took seven attempts, with reverts along the way.
A template grid optimization took five iterations before it was right. A task system UI took four refinement cycles. Those aren’t outliers I’m confessing to — that’s a normal week.
Here’s the thing I didn’t expect, and it’s the most useful idea in this post. Experimentation got cheap, so the process got messier while the outcome arrived faster. When trying an approach costs twenty minutes instead of two days, you stop agonizing over the right design up front and just try four of them. From the outside that looks undisciplined. The commit history is full of reverts. But the working version lands sooner than it would have if I’d spent three days whiteboarding first.
That tradeoff is fine. You just have to go in knowing it. If your mental model is “I describe the feature and AI writes it correctly,” you will feel lied to in week one. That’s a fantasy, and the people selling it to you have never maintained the result.
Where AI was strong, and where it wasn’t
This is my own assessment after 13 months, not a benchmark:
| Type of work | How it went |
|---|---|
| New features, rapid prototyping | Excellent |
| UX and UI iteration | Excellent |
| Database migrations and schema generation | Excellent |
| Bug fixes, paired with real error logs | Very good |
| Complex refactors, with proper context | Good |
| Performance optimization | Weakest |
A few notes on why.
New features and UI iteration are where the gains are obvious and immediate. Going from a description to something clickable takes minutes. Then you look at it, hate a third of it, and change it — that loop is where most of the speed actually comes from, not from the first draft.
Bug fixes got dramatically better when I stopped describing the bug and started pasting the Sentry log. That’s the single most useful habit I picked up. A real stack trace, the breadcrumbs, the actual payload — that’s context the model can’t guess at and can immediately use. Describing a bug in prose is asking it to reconstruct evidence you already have.
Refactors work, but only if you feed the context. The failure mode is a plausible-looking change to a file that has three callers you didn’t mention.
Performance optimization was consistently the weakest. It needs domain knowledge the model doesn’t have — which query runs on every page load, which table has 400,000 rows in production and 12 in dev, which of these five things users actually wait on. AI will happily optimize the wrong thing beautifully. Every real performance win I got came from me deciding what to look at, then using AI to execute the fix.
The guardrails are the whole game
Speed without a safety net is just a faster way to break production. What made this work wasn’t the tools. It was boring engineering discipline that I did not skip:
- Feature flags on anything meaningful, so a bad release is a toggle and not a rollback.
- Every schema change through a proper migration. No exceptions, ever.
- Sentry monitoring, which caught issues early and then fed the fixes.
- Vitest tests covering the paths that matter.
- A clean dev → staging → production flow. Nothing skipped a step.
- Iterative refinement with code-review passes. I read the code. All of it.
That last one is the one founders want to skip. Don’t. Reviewing AI-written code is faster than writing it, but it is not optional, and it’s the difference between 253 clean merges and a codebase nobody can touch in six months.
What I’d tell you if you’re weighing this up
Ship something every week. That’s the standard I hold now: small features every two or three days, medium features in about two weeks, large ones in four to six weeks maximum. If a quarter goes by and your customers haven’t seen anything new, you’re behind — and the gap compounds, because the competitor who ships weekly is also learning weekly.
The constraint is usually not talent. A founder I’m working with right now waits weeks on features because his technical advice and his technical delivery come from the same place. There’s nobody to build the thing while the same person is still deciding what the thing should be. That’s an organizational problem, and AI tooling only helps once it’s named.
And one honest caveat, since the whole point of this post is honesty: the numbers above are mine, on a codebase I knew cold, in a domain I’d worked in for twenty years. Context is the fuel. If you drop these tools on a system nobody understands, you get fast, confident, wrong code. The multiplier is real, but it multiplies what you already know.
If you’re trying to work out what this would look like on your codebase — what’s realistic, what to guardrail first, where it’ll fall over — that’s the work I do now. Here’s how I help with AI development, or tell me what you’re stuck on and I’ll give you an honest read on it. No pitch either way.
← All writing