Imagine you're building a web app that takes a long, messy list of contacts, leads, or company names and removes near-duplicates. You go to lovable.dev and type something like this:
Build a web app called Clean. Users upload a CSV or Excel file, choose which column to deduplicate on, set a similarity threshold using a slider, and download the cleaned file. The app should support fuzzy matching, not just exact duplicates. Design should be minimal and professional, data-tool aesthetic, muted colour palette, no unnecessary decoration. Primary action always visible. No sign-up required for a first use.
Hit enter and a few minutes later, there it is.
Pretty cool, right?
Three minutes to build. Weeks to fix what you didn't know to think about. That's the gap this guide closes.
Every mistake in this article happened while I was actively using LLMs to guide me through everything from writing code to pricing, distribution, and compliance. The tools weren't the problem. Not knowing what to ask was.
This guide covers the basics of everything between a first Lovable prompt and a live product (authentication, payments, security, compliance, SEO, and the infrastructure decisions that will matter once you have real users) and links to deep-dives where relevant.
What's a web app, and should you build one?
A web app is an application that runs in the browser, designed to be used on a desktop. Think of tools like Figma or Airtable, the kind of thing where you'd be annoyed if someone handed you a phone to use it. Web apps store data, manage user accounts, handle payments, run logic in the background. A static website tells you things. A web app does things.
Is this the right format for your idea? If what you have in mind lives on mobile (something people do on the go, uses the camera, or works best in short bursts) this isn't the right guide for you. Web apps are for sitting down. What we're building here also won't be publishable on the App Store, which is worth knowing upfront if that's part of your distribution plan.
Clean (the tool from the prompt above) is something I actually built and launched. For it, desktop is clearly the right medium: cleaning a CSV is the kind of task you sit down for, with a screen wide enough to actually see what you're working with. We'll use it as a running example throughout: the decisions I made, the ones I got wrong, and what I'd do differently.
Market research
Building fast is one of the great things about AI tools. Building the wrong thing fast is still expensive.
Market research is how you construct a hypothesis, specific enough to act on, that someone will pay for what you're offering before anyone ever has. It shapes what you build, what you charge, who your competitors are, and who you sell to first. It won't give you all the answers (the market will correct you once real users show up), but it saves you from building something nobody wants and tells you what to watch for when they do.
The goal is specificity. Not "people have messy data" but "sales reps searching 'dedupe two CSVs' are a different buyer than ops teams searching 'data deduplication software': different urgency, different budget, different tolerance for setup friction." That gap is a product, a price point, and a go-to-market strategy in one insight. One shortcut: solve your own problem, or your friends'. You already know where existing solutions fall short.
Under the hood: how web apps are built
The more you understand the basic architecture of a web app, the better you can direct Lovable (or your web app builder of choice) toward something that makes sense for what your tool will eventually need to do, not just what it does today. It's the difference between telling a contractor "build me a room" and knowing enough to say "I'll need plumbing in that wall eventually." One of those conversations saves you a very expensive renovation later.
Every web app is made up of three types of components.
Frontend is everything the user sees and interacts with: the layout, the buttons, the forms, the logic that says "when someone clicks this, show that." In Lovable's case, it's written in React, a popular frontend framework, and lives in a GitHub repository Lovable creates on your behalf. For Clean: the upload interface, the column selector, the settings panel, the download button, all frontend. One thing worth knowing: frontend code is readable by anyone. Open any website in your browser, right-click, hit Inspect, and what you see is the frontend. That matters for what belongs there and what doesn't.
The second is a database, where anything that needs to persist is stored. User accounts, processing history, pricing tier, anything that should still be there when a user comes back tomorrow. Without one, every page refresh wipes everything: no user, no history, no trace of what just happened. Lovable uses Supabase for this, which also hosts edge functions (small pieces of server-side logic that run outside the browser without requiring a full backend). Think of them as the connective tissue between your frontend and anything heavier running elsewhere. Lovable can generate these.
The third is a backend, server-side logic that runs independently of the browser, on infrastructure you manage separately. You may not need one for your MVP. You will need one when the logic is too heavy, too slow, or too proprietary for the frontend, and since frontend code is publicly readable, proprietary logic doesn't belong there. For Clean, the backend runs on Google Cloud Platform: a proprietary matching algorithm, significantly faster than open-source alternatives, with preprocessing options (normalising case, stripping punctuation, removing company suffixes, sorting word order) that make a real difference on messy real-world data.
Lovable handles the frontend and connects to Supabase for the database. The backend, if you need one, is built separately; LLMs can help you write it, but it won't appear from a Lovable prompt alone. Knowing which layer a problem belongs to is what lets you ask the right question.
What goes in your database, and what doesn't
Now that you know what a database is, the more useful question is what belongs in it.
Anything that changes because a user did something: database. Accounts, processing history, settings, anything that should still be there when someone comes back tomorrow. Static content that only changes when you decide to update it (help pages, comparison tables, blog posts): frontend code. That distinction will save you a painful migration later. The rule: if it changes because a user did something, it belongs in the database. If it changes because you decided to change it, it belongs in the code.
One thing to get right early: decide what data you'll want later and make sure you're capturing it now. Usage counts, timestamps, key user actions: nearly impossible to reconstruct after the fact.
That's it for part 1. Read the full web app AI solo-builder guide or wait for part two on here.
I write about the things I learn while building solo with AI. Follow along at https://randomsolobuilder.ai/
Top comments (0)