From broken prototype to real product
Exact fixes for apps built with AI tools, and plain guides to launching, pricing and designing an MVP. Written by me, from real projects.
Start with a complete guide
The complete guide to fixing a vibe-coded appWhat breaks in apps built with Lovable, Bolt, v0, Cursor and Replit, and how to fix it properly.All fixing articlesFrom prototype to product: launching an AI-built app properlyPayments, hosting, analytics, GDPR and first users: taking an AI-built prototype live.All launching articlesHow to build an MVP in 2026: scope, cost and processScope, cost, timelines and who to hire, with UK prices.All building articlesDesign for AI-built apps: making it not look AI-madeMaking an AI-built product look and feel like it was designed on purpose.All design articles
Fixes by tool
Latest
10 security holes in vibe-coded apps (and how to close them)The holes that matter most are tables without Row Level Security, policies that let everyone in, secret keys shipped to the browser, roles stored where users can edit them, server endpoints that check login but not ownership, and unverified payment webhooks. Each has a specific fix you can test in minutes.Adding Stripe payments to an AI-built app properlyCreate Checkout Sessions on the server, then grant access only from a webhook whose Stripe signature you have verified, using the raw request body. Make fulfilment safe to run twice, test with sandbox keys and test cards, then register a separate live webhook with its own signing secret.Adding the error handling AI tools skipAI tools build the path where everything works, so failed requests, bad input and crashes get a blank screen or nothing at all. Add an error boundary (error.tsx in Next.js) for crashes, check every fetch and Supabase result, return expected errors as values, show a toast for failed actions, and log errors somewhere you will see them.Analytics and tracking for a new app, set up rightDecide the three to five questions your MVP must answer, then track only the events that answer them, with one naming pattern. Use a cookieless tool such as Plausible for traffic, send important events like sign-ups from your server, and keep Stripe as the source of truth for revenue. Under UK rules, anything beyond the ICO's analytics exception needs consent.Bolt app slow: is it the preview, the published site or the database?First work out which part is slow. The Bolt preview runs a development server inside your browser using WebContainers, so it depends on your computer and is slower than the published build. If the published site is slow, look at image weight, database queries and row level security policies, and check the Logs page within the hour.Bolt auth not working: fixing sign-in, Google login and reset emailsMost Bolt login problems trace back to four things: the Site URL and URI allow list in the database's Authentication settings, testing Google sign-in inside the preview instead of the published site, the default limit of 2 auth emails per hour, and table policies that never check who is signed in. Fix them in that order.Bolt database issues: permission errors, paused databases and missing dataMost Bolt database issues come from how Bolt Cloud behaves, not broken code. New tables are private by default since 30 October 2026, unpublished projects pause after six days of low use, restoring a version rolls back code but not the database, and duplicates start with an empty copy. Find which one you hit, then fix permissions, restart, or realign the schema.Bolt mobile layout broken: fixing a Bolt web app on phones, and when you need ExpoCheck the layout in Bolt's Responsive mode and on a real phone using the published site, then fix overflow, fixed widths, viewport height and tap targets in the code. If you need an app-store app rather than a website, Bolt's docs say web projects don't easily switch to mobile, so start an Expo project with the words mobile app in the first prompt.Bolt SEO: why your Bolt site isn't showing up in Google and how to fix itIf your Bolt project is a client-rendered Vite app, crawlers that don't run JavaScript see one near-empty HTML file with the same title on every URL. Publish publicly on a custom domain, use real paths instead of #/ URLs, give each route its own title and description, add robots.txt and a sitemap in public/, and prerender the pages that need to rank.
See if BlackFig fits what you’re building (it probably does)
A quick 20 minute call. No slides, no hard sell. You leave with a clear next step either way.