A prototype proves an idea can work. A production-grade MVP proves real users can rely on it on an ordinary Tuesday, when traffic is uneven, a payment provider is slow to respond, and the person who built it is on leave.
The feature list is often identical. The difference sits underneath: how users sign in, what happens when an external API times out, whether anyone finds out the app is down, and whether the code can be handed to another team without weeks of archaeology. Below is the list we work through on every build, and what we think is reasonable to leave out.
Authentication, access and security basics
Prototypes often run on a hardcoded test account or no login at all. A production MVP needs real authentication from the first user.
- Use an established auth provider or library. Password hashing, session expiry, email verification and password resets are solved problems. Writing your own is how breaches happen.
- Roles from day one. Even if there are only two, such as admin and customer, enforce them on the server. Hiding a button in the interface is not access control.
- Secrets out of the code. API keys and database credentials belong in environment variables or a secrets manager, never in the repository.
- HTTPS everywhere, including internal admin screens.
- Input validation on every form and API endpoint, plus parameterized database queries.
- Rate limiting on login, sign-up and any endpoint that sends email or calls a paid API, so one script cannot run up your bill.
- Dependency updates. An automated check for known vulnerabilities in third-party packages costs almost nothing to set up.
Error handling, logging and monitoring
In a prototype, an error is a stack trace in the developer’s terminal. In production, it is a user staring at a blank screen while you remain unaware anything happened.
- Handle the expected failures. Payment declined, file too large, third-party API unavailable. Each should show the user a clear message and leave data in a consistent state, not a half-created order.
- Retries with limits. Calls to external services should retry a small number of times with a delay, then fail cleanly and record what happened.
- Structured logs. Log requests, errors and key business events (sign-up, payment, booking) with enough context to trace a problem, and without passwords, card data or other sensitive fields.
- Error tracking. A service that captures exceptions and alerts someone, so a bug reported once by a user is already on your list.
- Uptime checks. An external ping every few minutes that notifies a named person when the site stops responding.
Backups and separate environments
Two habits prevent most of the worst days in a young product’s life.
Backups that have been restored at least once
Automated daily database backups, kept for an agreed period and stored separately from the main server. Uploaded files need the same treatment. The step most teams skip is testing a restore. A backup that has never been restored is only a hope, and the time to find that out is before launch.
Development, staging and production
At minimum, keep production separate from wherever changes are tested. A staging environment with realistic but non-sensitive data lets you check a release before customers see it. Each environment gets its own database, its own keys, and payment providers in test mode outside production. Nobody should be testing a new checkout flow against live card payments.
Tests and a deployment pipeline
An MVP does not need exhaustive test coverage. It needs tests on the paths that would hurt most if they broke.
- Sign-up, login and password reset.
- Anything that takes or calculates money.
- The core action the product exists for, such as making a booking or submitting an application.
- Permission checks: confirm a customer cannot see another customer’s data.
Those tests should run automatically on every change, through a deployment pipeline that builds the app, runs the tests and deploys only if they pass. The pipeline also makes releases repeatable: deploying becomes a routine action rather than a careful sequence of manual steps that only one person remembers. Make sure rollback to the previous version is just as simple.
Documentation and ownership handover
A prototype is often understood by one developer. A production MVP should be understandable by the next one. Handover should include:
- A README covering how to run the project locally, configure environments and deploy.
- A short architecture note: main components, external services, and why key decisions were made.
- A list of every third-party account (hosting, domain, email, payments, analytics, AI APIs), registered in the client’s name with the client as owner.
- The full source code in a repository the client controls.
- A runbook for common incidents: what to check when the site is down, how to restore a backup, how to rotate a leaked key.
We treat this as a principle, not a deliverable: the client owns the code, the accounts and the data. If the relationship ends tomorrow, they should lose nothing.
What is reasonable to leave out
Production-grade does not mean enterprise-grade. These can usually wait until real usage justifies them:
- Multi-region hosting and complex autoscaling. A single well-sized server or managed platform handles far more traffic than most MVPs see in year one.
- Microservices. A well-organized single application is easier to run and change at this stage.
- Full test coverage. Cover the critical paths and add tests as bugs appear.
- Single sign-on, detailed audit trails and fine-grained permissions, unless a specific customer contract requires them.
- Polished admin dashboards. A simple internal screen or direct database reports often suffice early on.
- Native mobile apps, when a responsive web app serves the first users well.
Example (hypothetical): an online booking tool for a physiotherapy practice with three clinics. It needs secure patient logins, reliable reminders, daily backups, error alerts and tests on the booking and cancellation flow. It does not need a native app, a reporting suite or infrastructure built for a national chain. Those can follow once the practice sees which features patients actually use.
Next step: audit what you already have
If you have a prototype, go through the sections above and mark each item as done, partial or missing. The missing items in authentication, backups and monitoring are the ones to fix before you invite paying users; the rest can be scheduled.
If you are starting from scratch and want a fixed-scope build that includes these foundations from day one, see how our production-grade MVP process works: deployable software in about seven days, at a fixed price, with 100% of the code owned by you.