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.
Process
My 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.
Why 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.
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 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.
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 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 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.
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.
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.
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.
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.
Stack
Nuxt 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
Why 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: Commit, Shape, Pause or Decline
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.
More in this topic
Follow the build → — one practical finance-systems pattern, product decision or build lesson every two weeks.