How I Built 100+ Apps With AI (and What Most People Get Wrong About It)

It was past one in the morning when I shipped another small tool — a Spanish autónomo tax calculator. A tool with an audience small enough that no agency would quote it and no team would staff it. The kind of thing that, three years ago, would have stayed a note in a file called “someday.” That night it stayed a note for about forty minutes, and then it was live.

People hear “100+ apps” and assume the story is speed. That AI writes code fast, so I wrote a lot of code. That’s the boring version, and it’s mostly wrong.

The thing that actually changed

Writing code was never the bottleneck for a small app. I could always write the calculator. The bottleneck was finishing it — the last twenty percent that turns a working script into a thing a stranger can use. The edge cases. The blank input. The currency that rounds wrong. The copy that explains what the number means. The deploy. The tiny ongoing tax of keeping it alive.

That last twenty percent used to cost more than the first eighty. And for a narrow tool — a Beckham-law tax calculator used by a few thousand people in one country — the math never closed. Finishing cost more than the tool was worth. So it didn’t get built. Not because the idea was bad. Because it couldn’t justify the hours.

AI didn’t make me a faster coder. It collapsed the cost of finishing.

That’s the whole reframe. When the cost of finishing a focused tool drops far enough, a portfolio of narrow tools becomes viable where each one, alone, couldn’t have justified the time. The ideas didn’t change. The threshold did. Things that were never worth building were suddenly worth building.

What makes it actually work

A low threshold isn’t a method. If collapsing the finishing cost were the whole story, everyone would have a hundred apps. They don’t. Four things separate a portfolio from a graveyard of half-built repos.

Pick problems narrow enough to finish. The instinct is to build the big flexible thing — a calculator that handles every EU market at once. That’s the trap; the big thing never finishes. A tool scoped to one country’s net-salary contributions has a definite edge: a moment where it is done. Narrow isn’t a limitation. Narrow is what makes finishing possible.

Treat each app as a system, not a one-off. A one-off is a thing you build and abandon. A system shares its bones with the next one. Every app I ship inherits the same skeleton — input handling, number formatting, how it explains a result, the deploy. So app number sixty isn’t built from scratch. It’s built from fifty-nine prior decisions I no longer have to make again.

Reuse the scaffolding ruthlessly. This is where the count comes from. The fortieth tax calculator and the forty-first differ in maybe ten percent of their substance — the local rule, the local rate, the local exception. The other ninety percent is scaffolding I’d already solved. AI is unreasonably good at filling in the ten percent against a structure I hold firm. The structure is mine. The variation is fast.

That’s the actual engine. Not “AI writes apps” — a stable system, plus a fast way to vary it.

What AI does not remove

Here’s the part the speed story gets dangerously wrong. The collapse in finishing cost is real, but it lands only on the mechanical work. It doesn’t touch the judgment — and the judgment is most of the job.

Deciding what’s worth building. A low threshold means I can build almost anything. That makes the deciding harder, not easier — most ideas that pass the “can I build it” test still fail the “should this exist” test. AI will happily help me build the wrong tool perfectly. The filter for which narrow problem actually has people behind it is mine, and no model has opinions about that.

Owning the edge cases. A tax calculator that’s right ninety-eight percent of the time is worse than useless — it’s a liability with a clean interface. The two percent is the whole product. AI drafts the happy path beautifully and is confidently wrong at exactly the margins that matter: the threshold where a rule flips, the year a rate changed, the exemption nobody documents. I own those. Every one. That’s not work AI removed — it’s work it made more important, because it produces the confident wrong answer faster than ever.

The boring maintenance. A hundred apps is a hundred things that can break. A rate changes in January. A dependency goes stale. The portfolio that’s cheap to build is not cheap to keep. That tax never went away — it moved from before launch to forever after, and forever is longer.

So I’ll correct the headline myself. AI didn’t make me build apps faster. It moved the cost from making to deciding and maintaining — and those were always the parts that needed a person.

The reframe

The story isn’t a coder who got fast. A faster coder still wouldn’t have built a hundred-plus narrow tools, because speed was never what stopped them — the finishing cost did, one tool at a time, each one quietly not worth it.

What changed is that the finishing cost fell below the line where a narrow idea pays for itself. And below that line is a whole country of tools that were always good ideas and never good investments: the single-country autónomo calculator, the Croatian net-salary tool, the tax estimator for one expat regime — the utility that helps a few thousand people and no one else.

AI didn’t make me a better builder. It made the ideas that were never worth building suddenly worth building.

Which is why I was awake at one in the morning shipping a calculator nobody else would build — not because it was hard, but because, for the first time, it was finally worth the forty minutes. If you’ve got an idea like that, sitting in a “someday” file because it could never quite justify the hours, that’s exactly the kind of thing worth a conversation. See the portfolio →