Topic
Building AI Products
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.
My Product Operating System for Building Multiple AI Apps
The repeatable system I use to build several focused AI products solo — from choosing which problem to build, to shipping fast without letting AI make the decisions, to killing what isn't working.
How I Decide Whether an AI Product Idea Is Worth Building
The short filter I run every product idea through before writing a line of code — real recurring problem, a one-sentence outcome, small enough to ship solo, a path to someone caring, and would I use it myself.
Why I Write the Expected Output Before the Screen
Before designing any screen, I write the exact result the user should get — because the screen is only the path to an outcome. Design the UI first and you fall for an interface before you know its job.
How I Use AI Without Letting AI Make Product Decisions
AI is exceptional at execution and dangerous as a decider. The line I hold: AI does the how — code, scaffolding, drafts — and I keep the what and why: problem, outcome, cuts and pricing.
Why Most AI-Built Apps Feel Like Demos
AI-built apps often look finished and solve nothing — because AI made the product decisions, not just the code. AI optimizes for plausible; products win by being pointed. The difference, and how to avoid it.
Nuxt and Supabase as a Solo SaaS Stack
The stack I run every product on: Nuxt for the full-stack app (SSR, API routes, SEO), Supabase for auth, Postgres and storage. Why one boring, repeated stack is what lets a solo builder ship multiple products.
Why I Built Delivery Sheet
The same failure happened on every programme I worked: vague leadership asks became commitments before anyone knew the scope, owner or outcome. Delivery Sheet is the tool I wished existed — shape the ask before you commit.
Why I Built Listemizde Without Sponsored Rankings
The platforms people use to find local businesses are corrupted by paid rankings — the top result is whoever paid, not whoever's best. Listemizde ranks by real community trust: one person, one vote, no sponsored results.
My Kill Criteria for Product Experiments
I decide when to kill a product before I start it — by writing down what 'not working' looks like: no signal, no pull, no path to mattering. Kill criteria set in advance are what make running multiple experiments possible.
How I Decide Subscription or One-Time Pricing
The question isn't what's fashionable — it's the shape of the value. Ongoing value and use means subscription; a discrete result the user gets once means one-time. Match the price to the value, not the trend.
Why Delivery Sheet Has Four Decisions: Commit, Shape, Pause or Decline
Most teams have one real answer to an incoming ask: yes. Delivery Sheet forces one of four — commit, shape, pause or decline — because 'yes by default, no by neglect' is what quietly sinks delivery.
What I Learned Building Multiple Products at Once
Building several products solo taught me that focus isn't doing one thing — it's a system that gives each product the right attention at the right time, and kills what doesn't earn it. The lessons that made it survivable.
How I Turn a Rough Idea into a Claude Code Ticket
The gap between a rough idea and working code is precision. I close it by writing the outcome first, slicing the smallest useful piece, and specifying it tightly enough that an AI agent can build it without making the product decisions.
How I Think About Distribution as a Solo Builder
Distribution is the part solo builders skip and then wonder why nobody came. My answer: make it a first-class decision, and let the writing be the distribution — content that ranks and gets cited brings problem-aware people to the product.
Why I Don't Offer a Free Plan
Free plans attract people who'll never pay, create disproportionate support, and dilute focus from the users who actually value the product. For a solo builder, a free plan is a tax on attention. A free trial, yes — a free plan, no.
How I Scope an MVP
An MVP isn't the smallest thing you can build — it's the smallest thing that's actually useful. I scope it from the outcome: the one core result delivered to one real user, with everything else ruthlessly cut.
How I Get My First Users as a Solo Builder
The first users are the hardest — no momentum, no proof. My approach: don't broadcast to strangers. Go where the people with the exact problem already are, show them the specific solution, and let content compound.
Why I Build in Public
For a solo builder with deep expertise, the writing is the distribution, the trust and the accountability at once. Sharing the decisions and lessons behind the products brings the right people and compounds — building in silence is building without distribution.
How I Onboard Users to a Solo SaaS
Onboarding has one job: get the user to the core outcome as fast as possible. I design it backward from that outcome — the shortest path from signup to real value — and delete everything in between. Not a tour. Not a setup marathon.
Why I Build Narrow: Choosing Who a Product Is For
A product for everyone is a product for no one. Choosing exactly who it's for — a specific person with a specific problem — makes every decision easier and the product sharp. The narrower the who, the clearer the product.
How I Use Analytics as a Solo Builder
I track a handful of metrics that would actually change a decision — activation, retention, revenue — and ignore the vanity numbers that feel good but inform nothing. The test for any metric: would this change what I do?
How I Handle Support as a Solo Builder
Support isn't a cost to minimize — early on it's the highest-signal feedback I get. I do it personally, treat every ticket as product research, and cut volume by fixing the root cause, not by scaling the answering.
Confirm-before-destroy without the modal
A two-step destructive action pattern that keeps users in flow.
Follow the build → — one practical finance-systems pattern every two weeks.