[{"data":1,"prerenderedAt":219},["ShallowReactive",2],{"topic-building-ai-products":3,"topic-faq-building-ai-products":181,"topic-nav-counts-building-ai-products":215},[4,15,20,28,36,42,48,53,59,64,70,75,80,85,91,96,101,107,112,117,122,126,131,136,141,146,151,156,161,166,170,174],{"path":5,"title":6,"description":7,"type":8,"language":9,"date":10,"order":11,"cluster":12,"minRead":13,"cornerstone":14},"\u002Fblog\u002Fwhy-i-built-yollardayiz","Why I Built Yollardayız","Why I built Yollardayız: countless families drive Europe–Turkey each summer planning border crossings on Facebook hearsay. I built the live-data answer.","text",null,"2026-08-14",8.3,"case-study",3,false,{"path":16,"title":17,"description":18,"type":8,"language":9,"date":10,"order":19,"cluster":12,"minRead":13,"cornerstone":14},"\u002Fblog\u002Fwhy-yollardayiz-shows-its-sources","Why Yollardayız Shows the Source of Every Number","Every wait time in Yollardayız is labeled — official feed or traveler report, with its age. Credibility is the moat when the competition is hearsay.",11.2,{"path":21,"title":22,"description":23,"type":8,"language":9,"date":24,"order":25,"cluster":26,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fbuild-vs-buy-ai-feature","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.","2026-07-29",5.7,"deciding",4,{"path":29,"title":30,"description":31,"type":8,"language":9,"date":32,"order":33,"cluster":34,"minRead":35,"cornerstone":14},"\u002Fblog\u002Fai-product-unit-economics","AI 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.","2026-07-28",8.5,"economics",6,{"path":37,"title":38,"description":39,"type":8,"language":9,"date":40,"order":41,"cluster":26,"minRead":35,"cornerstone":14},"\u002Fblog\u002Fhow-i-decide-what-to-build-next","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.","2026-07-25",16.5,{"path":43,"title":44,"description":45,"type":8,"language":9,"date":40,"order":46,"cluster":47,"minRead":35,"cornerstone":14},"\u002Fblog\u002Fhow-i-handle-auth-and-user-data-solo","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.",6.5,"stack",{"path":49,"title":50,"description":51,"type":8,"language":9,"date":40,"order":52,"cluster":26,"minRead":35,"cornerstone":14},"\u002Fblog\u002Fhow-i-position-a-product","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.",20.5,{"path":54,"title":55,"description":56,"type":8,"language":9,"date":40,"order":57,"cluster":58,"minRead":35,"cornerstone":14},"\u002Fblog\u002Fhow-i-stay-sane-building-products-solo","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.",22.5,"growing",{"path":60,"title":61,"description":62,"type":8,"language":9,"date":40,"order":63,"cluster":58,"minRead":35,"cornerstone":14},"\u002Fblog\u002Fhow-i-write-a-product-landing-page","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.",17.5,{"path":65,"title":66,"description":67,"type":8,"language":9,"date":68,"order":69,"cluster":26,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fhow-i-decide-whether-an-ai-product-idea-is-worth-building","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.","2026-07-24",2,{"path":71,"title":72,"description":73,"type":8,"language":9,"date":68,"order":74,"cluster":58,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fhow-i-get-my-first-users","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.",17,{"path":76,"title":77,"description":78,"type":8,"language":9,"date":68,"order":79,"cluster":58,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fhow-i-handle-support-as-a-solo-builder","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.",22,{"path":81,"title":82,"description":83,"type":8,"language":9,"date":68,"order":84,"cluster":58,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fhow-i-onboard-users-to-a-solo-saas","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.",19,{"path":86,"title":87,"description":88,"type":8,"language":9,"date":68,"order":89,"cluster":90,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fhow-i-scope-an-mvp","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.",16,"building",{"path":92,"title":93,"description":94,"type":8,"language":9,"date":68,"order":95,"cluster":58,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fhow-i-think-about-distribution-as-a-solo-builder","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.",14,{"path":97,"title":98,"description":99,"type":8,"language":9,"date":68,"order":100,"cluster":90,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fhow-i-turn-a-rough-idea-into-a-claude-code-ticket","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.",13,{"path":102,"title":103,"description":104,"type":8,"language":9,"date":68,"order":27,"cluster":90,"minRead":105,"cornerstone":106},"\u002Fblog\u002Fhow-i-use-ai-without-letting-ai-decide","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.",5,true,{"path":108,"title":109,"description":110,"type":8,"language":9,"date":68,"order":111,"cluster":58,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fhow-i-use-analytics-as-a-solo-builder","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.",21,{"path":113,"title":114,"description":115,"type":8,"language":9,"date":68,"order":116,"cluster":26,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fmy-kill-criteria-for-product-experiments","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.",9,{"path":118,"title":119,"description":120,"type":8,"language":9,"date":68,"order":121,"cluster":26,"minRead":105,"cornerstone":106},"\u002Fblog\u002Fmy-product-operating-system","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.",1,{"path":123,"title":124,"description":125,"type":8,"language":9,"date":68,"order":35,"cluster":47,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fnuxt-and-supabase-solo-saas-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.",{"path":127,"title":128,"description":129,"type":8,"language":9,"date":68,"order":130,"cluster":58,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fsubscription-vs-one-time-pricing","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.",10,{"path":132,"title":133,"description":134,"type":8,"language":9,"date":68,"order":135,"cluster":90,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fwhat-i-learned-building-multiple-products-at-once","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.",12,{"path":137,"title":138,"description":139,"type":8,"language":9,"date":68,"order":140,"cluster":12,"minRead":13,"cornerstone":14},"\u002Fblog\u002Fwhy-delivery-sheet-has-four-decisions","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.",11,{"path":142,"title":143,"description":144,"type":8,"language":9,"date":68,"order":145,"cluster":58,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fwhy-i-build-in-public","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.",18,{"path":147,"title":148,"description":149,"type":8,"language":9,"date":68,"order":150,"cluster":26,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fwhy-i-build-narrow-choosing-who-a-product-is-for","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.",20,{"path":152,"title":153,"description":154,"type":8,"language":9,"date":68,"order":155,"cluster":12,"minRead":13,"cornerstone":14},"\u002Fblog\u002Fwhy-i-built-delivery-sheet","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.",7,{"path":157,"title":158,"description":159,"type":8,"language":9,"date":68,"order":160,"cluster":12,"minRead":13,"cornerstone":14},"\u002Fblog\u002Fwhy-i-built-listemizde-without-sponsored-rankings","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.",8,{"path":162,"title":163,"description":164,"type":8,"language":9,"date":68,"order":165,"cluster":58,"minRead":27,"cornerstone":14},"\u002Fblog\u002Fwhy-i-dont-offer-a-free-plan","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.",15,{"path":167,"title":168,"description":169,"type":8,"language":9,"date":68,"order":13,"cluster":90,"minRead":13,"cornerstone":14},"\u002Fblog\u002Fwhy-i-write-the-expected-output-before-the-screen","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.",{"path":171,"title":172,"description":173,"type":8,"language":9,"date":68,"order":105,"cluster":90,"minRead":27,"cornerstone":106},"\u002Fblog\u002Fwhy-most-ai-built-apps-feel-like-demos","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.",{"path":175,"title":176,"description":177,"type":178,"language":9,"date":179,"order":180,"cluster":90,"minRead":69,"cornerstone":14},"\u002Fblog\u002F04-confirm-before-destroy","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.","pattern","2026-05-13",23,[182,193,204],{"path":102,"title":103,"order":27,"faq":183},[184,187,190],{"question":185,"answer":186},"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.",{"question":188,"answer":189},"Why do AI-built apps often feel like demos?","Because AI made the product decisions. AI generates what's plausible and average — the most likely next thing — which is exactly wrong for a product, whose value comes from being pointed at a specific real problem and cutting everything else. When AI decides what to build, you get something that looks finished and coherent but isn't sharply solving anyone's actual problem. The fix isn't less AI; it's keeping the product judgment human and using AI only to execute those human decisions quickly.",{"question":191,"answer":192},"What product decisions should a human always keep from AI?","The what and the why: which problem to solve, what outcome defines success, what to deliberately leave out, and how to price. These are judgment calls that depend on lived understanding of a real problem and a point of view — precisely what AI lacks. AI can inform them with options and drafts, but the decision has to be yours, because those decisions are what make a product pointed instead of generic, and pointed is the whole value.",{"path":118,"title":119,"order":121,"faq":194},[195,198,201],{"question":196,"answer":197},"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.",{"question":199,"answer":200},"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.",{"question":202,"answer":203},"Should a solo founder use AI to build products?","Yes, for leverage — but with a hard line. AI is exceptional at execution: scaffolding, code, boilerplate, first drafts, moving fast. It should not make the product decisions — what problem to solve, what the outcome is, what to cut, what to charge. Used as a fast executor under human product judgment, AI lets one person ship what used to take a team; used as the decider, it produces polished apps that solve nothing in particular.",{"path":171,"title":172,"order":105,"faq":205},[206,209,212],{"question":207,"answer":208},"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.",{"question":210,"answer":211},"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.",{"question":213,"answer":214},"How do you avoid building an app that feels like a demo?","Make the product decisions yourself and use AI only to execute them. Start from a real problem you've hit repeatedly, write the outcome in one sentence, decide ruthlessly what to cut, and only then let AI build fast. The moment you let AI decide what to build, it smooths toward the generic and you get a demo. Keep the what and why human — problem, outcome, cuts, pricing — and AI becomes a fast way to build a pointed product instead of a plausible non-product.",{"enterprise-ai-transformation":155,"ai-workflow-design":35,"enterprise-ai-systems":89,"treasury-management-systems":111,"cash-and-liquidity-management":216,"treasury-risk-management":111,"treasury-systems-architecture":217,"sap-treasury":217,"finance-systems-delivery":218},31,32,27,1787475407352]