Idea to live site in a weekend with Lovable

Two days is enough to get something real on the internet with your name on it. It isn't enough to build a product, and confusing the two is how people end up with 9 abandoned projects and no users.

Here's what actually fits in a weekend.

Pick something with one screen

The projects that finish have a single main view. A calculator. A generator. A list with a filter. One thing the user does, one screen they do it on.

Projects that don't finish have accounts, dashboards, settings, billing, and an admin area. Each of those is a weekend on its own.

If your idea needs users to log in before they get value, cut the login. Almost every weekend project is better without auth, and you can add it later when someone asks.

Friday night: the prompt

Be specific about the thing and vague about the styling. Lovable is good at layout and bad at guessing your data model, so spend your words on the data.

Something like:

A single-page tool that takes a UK postcode and shows the
5 nearest EV charge points from a JSON file I'll provide.

Each result: name, distance in miles, connector type,
price per kWh. Sort by distance.

No accounts, no database. The JSON is bundled with the app.

That will get you something working in about 10 minutes. The first result is usually 80% right and confidently wrong about one thing.

Saturday: the 80/20 wall

You'll hit a point, usually around hour 4, where the generated changes start breaking things that already worked. Everyone hits it. It's not you.

What's happening is the context has filled up with the history of your project and the model is reasoning about a codebase it can only partly see.

Two things that help:

Change one thing per prompt. "Make the results cards instead of rows" works. "Make the results cards, add a loading state, and fix the mobile layout" produces a mess and you won't know which instruction caused it.

Describe the bug, not the fix. "The distance shows 0 for every result" gets you further than "change the distance calculation to use Haversine". You might be wrong about the cause, and if you name a fix you'll get that fix whether or not it helps.

Sunday morning: take the code

This is the step people skip.

Export to GitHub. Run it locally. Deploy it yourself to Vercel.

git clone <your repo>
npm install
npm run dev

Three reasons. You stop paying for the builder to host a static tool. You can use a proper editor when you hit something fiddly. And you own the thing, which matters more the longer it lives.

If it won't run locally, that's worth knowing on day 2 rather than month 6.

Sunday afternoon: the unglamorous 10%

The difference between a demo and something you'd put your name on:

• A title and meta description you wrote yourself, not "Generated by Lovable"
• A favicon
• It works on a phone (open it on your actual phone, not the responsive preview)
• An error state when the input is rubbish
• Your name and a link somewhere on the page

That's an hour of work and it's the hour that decides whether anyone takes it seriously.

Where the builders genuinely stop helping

Be honest about the ceiling.

They're excellent at CRUD screens, forms, and layout. They're fine at wiring up Supabase. They're poor at anything with real concurrency, at long-running jobs, at data pipelines, and at any logic where being subtly wrong looks the same as being right. Financial calculations, date arithmetic and anything involving timezones all fall in that last bucket.

If your idea's core is one of those, use the builder for the front end and write the logic yourself.

What to expect

Realistically: by Sunday evening you have one working tool, deployed, on a domain, that does one thing. Maybe 300 lines of code you didn't write and mostly understand.

That's a genuinely good weekend. It's also about 5% of what a product needs, so don't quit your job on Monday.

Ship it, put it somewhere people will see it, and see if anyone cares before you build the second screen.