How to launch an MVP without writing code — in one sitting

There has never been a better time to not know how to code.

That sentence would have been a setup for a joke five years ago. Today it's just true — with one large asterisk. The tools that build software from a description are genuinely remarkable, and they have also created a new kind of failure: the almost-launched MVP. Built, beautiful, and sitting in a preview tab forever because the last steps — backend, security, deployment — still assumed a developer would show up.

This guide is about clearing the asterisk. Not "how to generate a demo" — you can do that already — but how to get a working MVP live, with a real form or real accounts, on a real URL, in one sitting. No code, including the parts where no-code usually quietly becomes "some code."

A note before we start: an MVP deserves a validated idea. If you haven't tested whether anyone wants this, do the validation sequence first — it's a week of evenings and it will save you ten times that.

Step 0 — Shrink the MVP until it's embarrassing (15 minutes)

The classic MVP mistake isn't building the wrong thing. It's building too much of the right thing.

Write down your product's one core loop — the single action a user takes and the single result they get. Examples:

• "Paste a job description → get a tailored cover letter draft."
• "Submit a maintenance request → landlord sees it on a dashboard."
• "Pick a time slot → booking is recorded, both sides get an email."

Now cut everything that isn't that loop. No settings page. No teams. No dark mode. If removing it doesn't break the core loop, it goes. You're not building less because you're lazy — you're building less because every feature beyond the loop delays the only thing an MVP is for: learning whether the loop matters to anyone.

The honest test: if your MVP description doesn't feel slightly embarrassing, it's too big.

Step 1 — Write the build prompt (20 minutes)

AI builders are only as good as the description you give them. The good news: a great build prompt is not "prompt engineering" — it's just a clear spec in plain English. Cover five things:

1. What it is. "An app where freelance photographers collect shoot requests."
2. Who uses it. Visitors? Logged-in users? Both? (This decides whether you need accounts.)
3. The core loop. Spell out the action and the result, including what data gets stored: "Visitors fill a request form (name, email, date, type of shoot). I see all requests in a private dashboard."
4. The pages. List them: a public page explaining the service with the request form; a private dashboard listing submissions. Sections you list are sections you get.
5. The vibe. Two or three adjectives and any strong preferences: "clean, warm, lots of white space."

Here's a complete example you can adapt:

"An MVP for ShootBook, a tool where freelance photographers collect and manage shoot requests. Public landing page: headline about never losing a booking inquiry, three short benefit points, and a request form (name, email, preferred date, type of shoot, message). Submissions are stored and visible to me in a private dashboard, newest first, with a way to mark each request as 'replied'. Tone: clean, warm, professional. Mobile-friendly."

Notice what's not in there: no database choices, no framework opinions, no deployment plan. In a tool that ends at code, those gaps become your homework. In a tool that ends at live, they're handled.

Step 2 — Build, and iterate in sentences (30–60 minutes)

Run the prompt. The first draft will be 80% right, and the remaining 20% is where non-technical builders traditionally got stuck — because fixing things used to mean reading what the AI wrote.

It shouldn't. Iteration should look like this:

• "Make the headline more direct."
• "Add a confirmation message after the form submits."
• "The dashboard should show the shoot type as a colored tag."

One change per message. Look at the result. Ask for the next one. Two to five rounds is normal; if a change breaks something else, say exactly that ("that broke the form — restore it and try a smaller change"), and if three consecutive fixes haven't converged, simplify the request rather than feeding the loop.

This is also where tool choice quietly matters most. A common complaint about AI builders is credit-burning debug loops — paying for fixes to bugs the tool introduced. However you build, watch for that pattern early; it's the difference between an afternoon and a lost month. (Our position at Kalit: we shouldn't profit from our own bugs.)

Test the loop like a stranger. Before publishing, run your core loop start to finish: submit the form with real-ish data, check it lands in the dashboard, mark it replied. If your MVP has accounts: register, log out, log back in, and confirm you only see your own data.

Step 3 — Publish: the step that used to be a weekend (5 minutes)

Here's where the "almost-launched MVP" graveyard fills up everywhere else: export the code, choose a host, configure the build, point the DNS, sort the SSL. Each step is small for a developer and a wall for everyone else.

With Kalit it's one click. Publish runs production checks — including the security hardening: HTTPS, server-side validation on that request form, rate limiting so bots don't bury you, no exposed keys — and hands you a live URL. Your MVP is now a real product on the internet, not a preview.

Custom domain: you can launch on the free yourname.kalit.app URL today and connect a domain later, or do it now in project settings — Kalit shows the exact DNS records and handles the certificate. (Custom domains come with Starter, €29/month.) For a first MVP, launching on the free URL today beats launching on the perfect domain next week.

Step 4 — Get it in front of ten real users (the same evening)

An MVP without users is a hobby with a URL. The bar is wonderfully low: you need ten relevant people, not ten thousand.

• If you ran the validation sequence, email your signup list: "It's live — here's the link. I'd love your honest reaction."
• Send it directly to people who feel the pain. A personal message with a working link converts shockingly well, because the link actually works.
• Post it where the problem gets discussed — same disclosure rule as ever: say it's yours.

Then watch what they do, not what they say. Real usage of the core loop — actual form submissions, actual bookings — is the only metric an MVP has.

Step 5 — Iterate weekly, in public if you dare

Every change from here is a sentence: "add an email notification when a request comes in," "let me export requests," "add a pricing section." Describe, preview, republish — the same one-click way it launched. Ship one improvement a week based on what users did, and your MVP compounds into a product.

And every published Kalit build comes with a one-tap share card — "I built and shipped this" with your live URL. Use it. Building in public starts with having something live to point at, and now you do.

The whole sitting, summarized

Shrink the scope (15 min) → write the prompt (20 min) → build + iterate (under an hour) → publish (one click) → ten users (tonight). The gap between "I have an idea" and "strangers are using my product" has collapsed from months to an evening — if your tool covers the whole distance, backend and security and deployment included, instead of stopping at the demo.

Start your MVP free → — describe the loop, publish it tonight, and let real users tell you what's next. No code. No cliffs.

Related:

How to validate your SaaS idea first

The 5 cliffs where people quit building with AI.