Building with AI Solo: What It Actually Teaches You

Three AI products in eighteen months, no team, no co-founder, no outside funding. That’s not a boast, it’s the condition under which I learned the thing this piece is actually about, because building alone removes every place to hide from what a tool can and can’t do, and from what it actually costs to keep running.

GuruCat was first, a mobile app running image recognition against cat photos to generate “psychic guidance” content — built, shipped to the App Store, and later delisted once the B2C unit economics didn’t hold up. Posterprints.art came next: a generative-AI e-commerce operation that’s grown to more than 600 SKUs across 29 collections, driven by Pinterest, still live and selling. Omega Praxis is the current one, a B2B platform running on the same solo-builder muscle, aimed at a harder problem.

What you learn building this way isn’t in any certification, because certifications teach tools, and the tool you’d get certified on this year is already partly obsolete by the time the course ships. Code generation is fast, that part of the hype is accurate. Architecture decisions are still entirely yours; the model will happily generate a structure that works for the demo and falls apart at scale, and it has no opinion on which one it just handed you. Debugging AI-generated code turned out to be its own skill, distinct from debugging your own code, because you’re reading logic you didn’t write and can’t fully predict, produced by something confident enough to never flag its own mistakes.

Quality control across 600 SKUs taught me more about where generative AI actually breaks than any benchmark I’ve read, because a benchmark tells you the average case and a live catalogue tells you the failure mode that shows up at SKU 340 and nowhere in the first fifty. That’s a narrow, repetitive, well-defined task with a clear success criterion, exactly the profile that a small local model handles well, and exactly the profile I’d now tell any solo builder to stop routing through an expensive general-purpose API call. The task fit isn’t a subtlety; drafting the client-facing product description is a weak fit for anything you’d run on your own machine, and belongs on the best cloud model you can afford, while classifying and tagging 600 SKUs against a fixed taxonomy is a strong fit for something smaller and cheaper running locally. Knowing that difference cold, because I was the only person who’d pay for getting it wrong, is not a line item any certification teaches.

Cost discipline works the same way when you’re solo as it does for an SMB owner sizing a local setup, except you feel every euro of it personally, with nobody else’s budget to absorb the mistake. Hardware, setup time, the hours spent keeping a model current, none of that shows up as a subscription invoice, it shows up as your own evenings. That’s the maintenance line every local AI cost estimate leaves out until someone forces the question of who actually does the four hours a month of updates and monitoring, and for a solo builder the honest answer is always “me,” which is exactly why I now default to cloud for anything that isn’t high-volume and narrow enough to earn its keep. The break-even math that makes sense for a thirty-person company weighing a back-room server doesn’t move the needle for one person; my volumes tend to justify the switch only for the most repetitive, highest-frequency task in the pipeline, and everything else stays on the general-purpose model I don’t have to maintain.

The deeper lesson sits underneath all three ventures rather than inside any one of them: the tool changes every few months, but the workflow, ideate, generate, evaluate, iterate, ship, hasn’t changed once across three completely different products in three completely different markets. That workflow is the actual transferable asset, and it now includes a decision I didn’t have to make explicitly two years ago: for each step, does this run on the general-purpose model, or does it earn a smaller, cheaper, narrower tool of its own. That workflow is almost never what gets taught, because most organisational AI training is still built around the tool of the moment, which gives it a shelf life measured in product-update cycles, and around a false binary between “the cloud” and “your own server” that doesn’t survive contact with a real catalogue.

What I’d actually want to teach a team, if I were running that programme, is the workflow underneath, the part that survives the next model release, the next pricing change, and the next local-versus-cloud debate that turns out to be neither new nor a debate you win once and for all. Whether that’s teachable at scale, outside solo conditions where the maintenance bill lands on nobody but you, is the open question I still don’t have a full answer to.