What actually happens in a 48-hour MVP build

The claim, and the honest version of it

"An MVP in 48 hours" sounds like marketing, so it is worth separating what is true from what is not.

True: a deployed web application with accounts, a database, a payment flow and one substantial workflow, built in 48 focused hours, that real people can use to get a real outcome.

Not true: that this is a finished product, that it has a bespoke design system, that it handles every edge case, or that it replaces the three-month build you would do if the idea works.

The 48 hours is a test, not a company. It exists so you find out whether anyone wants the thing before you spend $60,000 finding out.

Before the clock starts

This is the part that makes the rest possible, and the part that gets skipped in the sales pitch.

Days before the build, the scope is agreed in writing: three features, defined specifically, with an explicit exclusions list. Accounts and credentials are collected — domain access, any API keys, the payment account. Architecture decisions are already made, because the same stack is used every time and there is nothing to research.

By the time the clock starts there are no open questions. A build that begins with open questions is not a 48-hour build, it is a 48-hour argument.

Friday: foundations and the core workflow

Hours 0–2. Repository, deployment pipeline and database provisioned. The site is live on a real URL within the first two hours — empty, but live. Deploying early rather than at the end removes the single most common cause of last-minute disasters.

Hours 2–5. Data model and authentication. The data model is the decision with the longest shadow; getting it wrong on Friday is felt on Sunday. Auth comes from a proven pattern rather than being invented.

Hours 5–12. The core workflow — the one feature that is the actual product. Built properly, end to end, with real data in the database rather than placeholders.

End of day. A progress update with a link to the live site. Something works and you can click it.

Saturday: the hard half

Hours 12–20. The two supporting features. These are usually faster than the core one because the foundations now exist.

Hours 20–26. Payments, if in scope. This block is longer than people expect, and the reason is webhooks. Taking a payment is easy; reliably recording that a payment happened, even when the customer closes the tab or the network drops, is the part that quietly loses money in badly built products. Signature verification, replay protection, idempotency.

Hours 26–32. Email, error handling and the unglamorous correctness work: what happens on an empty state, a failed upload, a duplicate submission, a stale session.

End of day. Second progress update. All three features are usable.

Sunday: polish, deploy, hand over

Hours 32–38. Mobile layout and interface polish. Most first users arrive on a phone, so this is not cosmetic.

Hours 38–42. Search and AI visibility: metadata, structured data, a sitemap, robots rules and an llms.txt file. This is a few hours on build weekend and years of compounding value, and it is the part almost every rushed build omits.

Hours 42–46. Testing the paths a real user takes, on a real phone. Sign up, pay, do the thing, come back tomorrow.

Hours 46–48. Production deployment to your own domain, analytics wired in, repository transferred, and a 30-minute handover walkthrough recorded so you can watch it again.

The five things deliberately left out

1. A bespoke design system. The interface is clean and credible, built on a component library. A custom visual language is a separate project.
2. An admin back-office. For the first few weeks, the database is the admin panel.
3. Team accounts and permissions. Individual users only. Roles and seats are version two.
4. Automated test suites. Paths are tested by hand. Test coverage is the right investment once the product has survived contact with users and has a shape worth protecting.
5. Scale engineering. It will comfortably handle your first thousand users. It is not architected for a hundred thousand, and architecting for that before you have a hundred is the most common way to waste a build.

How to spot a fast build from an unfinished one

If you are considering anyone offering a rapid build, these are the questions worth asking:

• Is the scope fixed in writing before the build? If not, the 48 hours is aspirational.
• What is explicitly excluded? A confident answer here is the best signal you will get.
• What happens if it runs over? Ask for the specific commitment.
• Who owns the code, and when does the repository transfer? In Australia the developer keeps copyright by default unless assigned in writing.
• Are payment webhooks verified? A specific technical question with a right answer. Someone who has built payments properly will answer it immediately.
• Where do the API keys live? The answer must be "server-side only". Keys in the browser is the single most common security failure in fast builds.

A fast build is a scoping discipline, not a coding trick. Anyone selling the speed without the discipline is selling you the second half of the sentence.