Over nine months I built six AI products on my own: an LMS, a content engine, a sales agent, a hiring tool, a CRM, and a frontline-training app. One shared FastAPI + Supabase backend, all of it in public on GitHub. Claude Code wrote most of the code. I made the decisions.
For most of my career, shipping was the bottleneck. You scoped tightly because every feature cost engineering weeks. Roadmaps were really just queues — an honest admission that you couldn't build everything, so you ranked. That constraint did a lot of quiet work: it forced you to choose.
That constraint is mostly gone. When I can stand up a working product in days, "can we build it" stops being an interesting question. We can. The question underneath it — the one the old constraint was answering for me — is suddenly naked: should this exist, and who is it for?
The flagship taught me nothing. The flop did.
My flagship was the impressive one. Clean architecture, real B2B feature set, the thing I'd show another engineer. I was proud of the stack. Then I opened the analytics and there was nothing there — a handful of logins, all mine.
The weekend bot was the embarrassing one. Built fast, barely designed, solving one narrow annoyance for one narrow group of people. 49 of them found it and used it. I hadn't spent a rouble telling anyone it existed.
The difference wasn't quality of code — the flagship was better code. The difference was that the bot answered a question someone was already asking, in a place they already were. The flagship answered a question I found interesting.
When building costs collapse, the cost of building the wrong thing doesn't go down. It goes up — because now you can do it six times before you notice.
The demo is not the product
I see the same pattern from the other side, in the enterprise AI work I've done. A team gets a model to do something impressive in a meeting, everyone claps, and the project is declared real. Then the slow part starts: who actually uses this, how does it reach them, and how do we know when it quietly breaks?
Distribution and evals were the product the whole time. The demo was just the part that was easy to be excited about. AI made demos almost free, which means the demo now tells you even less than it used to.
What I'd do differently — and am
Decide distribution before building. Not "we'll figure out growth later." If I can't name where the first ten users come from, the product isn't ready to be built, however cheap building has become.
Write the eval before the feature. A feature without an eval is a guess wearing a deadline. With evals, a model swap is a measurable decision instead of a vibe; without them, you find out something regressed from a user, weeks late.
Kill faster. Of the six, the honest answer is that two earn their keep. The discipline now isn't building more — it's being willing to delete the impressive thing that nobody needed.
I used to think judgment was the soft part of product management, the stuff you added once the hard engineering was done. It turns out judgment was the hard part. The tools just got good enough to make that obvious.
I'm Dmitry — a product leader who ships AI products solo. I write about this as I go. If you're building something similar, or hiring for it, I'd like to hear about it: get in touch.
What's the most expensive "we built it, nobody came" lesson from your own AI projects?