An MVP has a small job. It has to stay up while you find out whether anyone wants it, and it has to keep their data safe while you do. That makes for a short hosting list. Most of what people add early costs time they could spend talking to users.
I split the list in two: what has to exist before the first real user, and what can wait until something tells you it's needed.
Set up before the first real user
A paid plan, even a small one
Free tiers are for trying things out, and the hosts say so. Render's docs tell you not to use free instances for production. A free web service there spins down after 15 minutes without traffic and takes about a minute to wake, and free Postgres databases expire after 30 days. Vercel's Hobby plan is limited to non-commercial, personal use. So pick a small VPS or cloud plan that you can resize without moving to a new server.
Backups you've restored
This is the item I'd never cut. In January 2017 an engineer at GitLab wiped a production database directory by mistake, and the company's postmortem tells the rest. The S3 bucket meant to hold the
pg_dump
backups was empty. A version mismatch had been stopping the backup job, and the failure alerts went out by email and were rejected, so nobody knew. Some data was never recovered. As Google's SRE book puts it, the thing people really want from backups is the restore.
So do three things. Run a nightly dump. Keep copies somewhere other than that server. Restore into a scratch database before launch, then once a month, and time it:
pg_dump -Fc mydb > nightly.dump
createdb restore_test
pg_restore -d restore_test nightly.dump
A managed database is a fair way to pay someone else for the nightly part. Run the restore anyway.
HTTPS that renews itself
Let's Encrypt doesn't charge for certificates. They last 90 days, and it recommends renewing every 60. Many hosting panels handle this for you, but check that yours does, then check again after the first renewal.
Accounts in your company's name
The domain, DNS and hosting should belong to the company, not to a freelancer. Make sure two people can log in. Getting a domain back from someone who stopped answering is a miserable way to spend a launch week.
Secrets outside the code
Database passwords and API keys belong in environment variables or your host's secret store, never in the repo. Give the app a database user that can't drop tables, and keep the admin login for yourself.
A locked-down server
Open ports 80 and 443, plus SSH with keys and no passwords. Your database shouldn't be reachable from the internet. Turn on automatic security updates.
Email that arrives
A password reset that lands in spam looks like a broken product. Gmail's sender rules require SPF or DKIM for everyone who sends to Gmail accounts, along with valid forward and reverse DNS. A transactional email service can handle most of that. Send yourself a test to a Gmail address and see where it lands.
One way to deploy, and one way back
Editing files over SSH leaves you with a version nobody can rebuild. Use one script or pipeline that deploys from your main branch, and keep the previous release ready so you can switch back quickly.
A check from outside
Your server can't tell you it's down. Set up an uptime monitor that runs elsewhere and messages your phone. Point it at a page that touches the database, so it fails when the database does. Add an alert for disk space, because a full disk will stop a database. And send alerts to more than one place, which is the other lesson from GitLab. Keep application logs for a couple of weeks too, because the bug report you get on Friday is often about Tuesday.
Leave these for later
Each of these earns its place at some point, and each comes with a sign that tells you when.
| Item | Add it when |
|---|---|
| Kubernetes | You run several services and someone's job includes looking after the cluster |
| Autoscaling | You've measured spikes that a bigger server can't absorb |
| Read replicas | Reads stay slow after you've added indexes and fixed the worst queries |
| Several regions | Customers far away complain, or a contract asks for it |
| A CDN | Images or video make pages slow for people far from your server |
| A separate staging server | A second developer joins, or paying customers depend on the product |
| A higher uptime target | A customer pays you for it |
Some arithmetic on that last row. At 99.9% uptime, a 30-day month allows about 43 minutes of downtime. With a few dozen users, 43 minutes in the middle of the night costs you very little. Losing a week of their data could end the product. That's why restores are on the day-one list and a second data center isn't.
The same logic works for server size. Start small, watch CPU, memory and disk for a few weeks, and resize when the graphs tell you to. On many VPS plans that takes minutes and no rebuild, so there's little reason to pay ahead for traffic you don't have yet.
Questions to ask before you pay
Ask your host:
- How often do backups run, and where are they stored?
- Can I restore one myself, or do I open a ticket and wait?
- Can I resize the plan without moving to a new server?
- Who answers at night, and how do I reach them?
- If I leave, can I export everything?
If an agency is building the MVP, hosting belongs in the quote. Rocketech, the company I founded, published a comparison of ten MVP companies, and its list of questions for founders includes who handles hosting after launch and what it costs. Another question on that list is what you get if you move to another team. The answer should include access to every service the product uses. Ask both before you sign.
One drill before launch
Pick a quiet evening and pretend the server is gone. Rent a new one. Deploy from the repo, restore last night's backup and point DNS at it. Time the whole thing, and write down every step you had to look up.
Those notes are your recovery plan. If the drill took longer than you could live with, fix that before you invite anyone in.
