Topic
Building AI Products Solo: How I Ship Focused Software
The build-in-public side of this studio: how I actually take a recurring problem and turn it into a small, sharp product — and just as often, how I decide not to. Idea selection, the process I run, using AI in the workflow without letting it make the product decisions, a solo Nuxt and Supabase stack, pricing, distribution, and when to kill an experiment.
Written from building real products with 18 years of enterprise-systems experience behind them — not indie-hacker theory, but what I've found works when you're shipping focused software on your own.
34 articles · ~149 min, in 7 sections — each in reading order
Deciding
7 articles · ~33 minMy Product Operating System for Building Multiple AI Apps
The product operating system I use to build several focused AI products solo: choosing which problem to build, shipping fast, and killing what isn't working.
How I Decide Whether an AI Product Idea Is Worth Building
How to decide what product to build: the short filter I run every idea through — real recurring problem, one-sentence outcome, small enough to ship solo.
Build vs Buy an AI Feature: Model, API or Off-the-Shelf?
Build your own model, call a hosted API, or buy an off-the-shelf tool? A solo builder's framework for the AI build-vs-buy call — and when each is the right one.
My Kill Criteria for Product Experiments
Product kill criteria set in advance — what 'not working' looks like: no signal, no pull, no path to mattering — are what let you run many experiments.
How I Decide What to Build Next
Deciding what to build next isn't the loudest feature request or the most satisfying refactor — it's the recurring problem I decided mattered, on purpose.
Why I Build Narrow: Choosing Who a Product Is For
Choosing a niche makes a product sharp: a product for everyone is for no one. Pick exactly who it's for and every decision gets easier. Narrower is clearer.
How I Position a Product (What It Actually Does)
Positioning is the one sentence that makes exactly the right person say 'that's for me' — a chosen problem and a chosen who, not a list of features.
Building
7 articles · ~26 minWhy I Write the Expected Output Before the Screen
Define the outcome before design: I write the exact result the user should get before building any screen, because the screen is only the path to an outcome.
How I Use AI Without Letting AI Make Product Decisions
Using AI to build products means AI owns the how — code, scaffolding, drafts — while I keep the what and why: the problem, outcome, cuts and pricing.
Why Most AI-Built Apps Feel Like Demos
Why AI apps feel like demos: they look finished but solve nothing — AI made the product decisions. It optimizes for plausible; products win by being pointed.
What I Learned Building Multiple Products at Once
Building multiple products at once taught me focus isn't doing one thing — it's a system giving each the right attention at the right time. The lessons.
How I Turn a Rough Idea into a Claude Code Ticket
My Claude Code workflow for turning a rough idea into working code: write the outcome first, slice the smallest piece, and spec it tightly for an AI agent.
How I Scope an MVP
How to scope an MVP: not the smallest thing you can build, but the smallest that's actually useful — one core result for one real user, everything else cut.
Confirm-before-destroy without the modal
Replace the 'are you sure?' modal with a two-step inline button that confirms in place — keeping users in flow and giving mistaken clicks a quiet way out.
Stack
2 articles · ~10 minNuxt and Supabase as a Solo SaaS Stack
The Nuxt and Supabase SaaS stack I run every product on: Nuxt for the full-stack app, Supabase for auth, Postgres and storage. One boring stack ships more.
How I Handle Auth, Security and User Data as a Solo Builder
Solo SaaS authentication done right: don't roll your own auth, collect the least data you can, and do the boring custodial parts deliberately.
Case Study
3 articles · ~9 minWhy I Built Delivery Sheet
Why I built Delivery Sheet: on every programme, vague leadership asks became commitments before anyone knew scope, owner or outcome. Shape before you commit.
Why I Built Listemizde Without Sponsored Rankings
Why I built Listemizde: local-business platforms are corrupted by paid rankings. It ranks by real community trust — one person, one vote, no sponsors.
Why Delivery Sheet Has Four Decisions, Not a Backlog
Most teams answer every ask with yes. Delivery Sheet forces one of four decisions — commit, shape, pause or decline — because 'yes by default' sinks delivery.
Economics
1 article · ~6 minAI Product Unit Economics: Cost, Margin and Control
An AI product has a variable cost per use that most SaaS doesn't. How I think about token cost per user, gross margin, caching, model routing and cost caps.
Engineering
4 articles · ~21 minPrompt & Model Versioning: Governance for AI Products
A prompt is production code and a model is a dependency you don't control. How I version prompts, handle model changes and stop silent regressions.
Production AI Observability: Watching What the Model Does
You can't fix what you can't see. How I observe AI features in production — quality, cost, latency, drift and failures — so problems show up as data, not churn.
AI Output Contracts & Failure Handling
A model will return garbage, the wrong shape, or a confident lie. How I design output contracts, validation and fallbacks so the product fails safely.
AI Evaluation & Regression Testing
How I build eval datasets for AI features — cases, scoring, regression gate — so a prompt or model change is judged on evidence, not three examples and hope.
Growing
10 articles · ~44 minHow I Decide Subscription or One-Time Pricing
Subscription vs one-time pricing comes down to the shape of the value: ongoing use means subscription; a one-off result means one-time. Match price to value.
How I Think About Distribution as a Solo Builder
Solo founder distribution is the part builders skip, then wonder why nobody came. Make it a first-class decision and let the writing be the distribution.
Why I Don't Offer a Free Plan
Why no free plan: they attract people who'll never pay, create heavy support, and dilute focus. For a solo builder it's a tax on attention. A trial, yes.
How I Get My First Users as a Solo Builder
How to get first users: don't broadcast to strangers. Go where people with the exact problem already are, show the solution, let content compound.
How I Write a Product Landing Page
A product landing page that converts names the visitor's problem and the outcome in the first line — not a hero of adjectives and features nobody reads.
Why I Build in Public
Why build in public: for a solo expert, the writing is distribution, trust and accountability at once. Sharing decisions brings in the right people.
How I Onboard Users to a Solo SaaS
SaaS onboarding has one job: get the user to the core outcome fast. Design it backward from that outcome — the shortest path from signup to real value.
How I Use Analytics as a Solo Builder
Analytics for a solo SaaS: track the few metrics that change a decision — activation, retention, revenue — and ignore the vanity numbers that inform nothing.
How I Handle Support as a Solo Builder
Solo SaaS support isn't a cost to minimize — early on it's the highest-signal feedback. Do it personally, treat every ticket as product research.
How I Stay Sane Building Products Solo
Solo founder sustainability: narrow scope so there's less to hold, kill dead experiments, and refuse to read a product's numbers as a verdict on yourself.
Free tools for this topic
Frequently asked questions
How do you build multiple products at once without losing focus?
With a repeatable operating system rather than fresh improvisation each time: I only build from real recurring problems I've actually hit, I define the outcome before I design a single screen, I use AI to move fast on execution while keeping the product decisions human, I ship on one solo-friendly stack so nothing is bespoke, and I apply explicit kill criteria so weak experiments die quickly. The system is what lets several small products coexist without any one of them consuming all the attention.
Full article →How should you use AI to build a product?
Use AI for execution and keep the product decisions human. AI is exceptional at the 'how' — scaffolding, code, boilerplate, first drafts, moving fast — and it lets one person ship what used to need a team. But it should not make the 'what' and 'why' decisions: what problem to solve, what the outcome is, what to cut, what to charge. AI optimizes for plausible rather than pointed, so left to decide it produces polished software that solves nothing in particular. As a fast executor under human product judgment, it's leverage; as the decider, it's a demo factory.
Full article →Why do so many AI-built apps feel like demos?
Because AI made the product decisions, not just the code. AI optimizes for what's plausible and average — the most likely next thing — while a real product wins by being pointed: sharply solving one specific problem and cutting everything else. So AI-decided apps come out looking finished and coherent but not actually solving anyone's problem badly enough to matter. The code isn't the issue; the missing thing is a human deciding what problem to solve, what the outcome is, and what to leave out.
Full article →What is a product operating system?
It's the small set of repeatable rules and steps you run every time you take an idea to a shipped product — how you choose what to build, how you define success before building, how you make decisions, what stack you use, and how you decide when to stop. For a solo builder shipping multiple products, it replaces per-project improvisation with a consistent process, which is what makes building several things at once sustainable instead of chaotic.
Full article →What is the difference between a demo and a product?
A demo shows that something can be built; a product solves a specific real problem for someone who will use or pay for it. Demos are broad, plausible and impressive; products are narrow, opinionated and useful. A demo answers 'look what's possible'; a product answers 'here's your problem, solved.' Most AI-built apps are excellent demos — they prove capability — but they never made the sharp, human decisions that turn capability into a product with a point.
Full article →Follow the build → — one practical finance-systems pattern, product decision or build lesson every two weeks.