App Hosting: Four Numbers to Ask For Before You Go Live

You are a few weeks from launch. The app works, your developer says it is "deployed", and someone forwards you a hosting invoice to approve. That invoice is the only part of app hosting most founders ever see, and it tells you almost nothing about whether your business survives a bad Tuesday.

Four numbers do tell you that. Ask for them before you go live, write the answers down where you can find them again, and you will understand your infrastructure better than plenty of companies spending ten times as much on it.

1. Cost per month, with every line in it

The number you are usually quoted is the server. The number you will actually pay includes everything the product needs to be reachable, remembered and watched. Ask for one figure per month, with the lines visible:

• Compute — the server or containers the app runs on.

• Database — and whether its backups are included or billed separately.

• File and image storage, plus the bandwidth to serve it.

• Domain, TLS certificate, DNS.

• Transactional email, SMS and push notifications — usually per message.

• Monitoring, error tracking, log retention.

• Build minutes for deployments, and any paid seats on the tools your team logs into.

Then ask the second half of the question, which almost nobody asks: what does this bill look like at ten times today's traffic? On a fixed server the answer is usually "the same, until we outgrow it, and then roughly double". On per-request pricing the answer can be a multiple you did not plan for, and you will not find out until the month a post about you does well.

Our bias for products in their first year is boring and predictable: one modest server, a managed database with automated backups, storage for uploads. At that size the whole thing is tens of dollars a month, not hundreds, and the bill does not surprise you. Elastic infrastructure is a solution to a problem you should be glad to have later.

2. Backup age: how old is the newest backup you could use right now

Do not ask "do we have backups". The answer is always yes. Ask this instead: if the database is destroyed at 14:00 today, what is the timestamp of the newest copy we can restore from? That gap — minutes, an hour, a day — is the amount of your business you have agreed to lose, and it is your decision, not your developer's.

An hour of lost data means something different for every product. For a content site it means one post. For a delivery platform doing a few hundred orders a day it means a morning of orders nobody can find, drivers already on the road, and a day of phone calls. Pick the gap you can live with, then pay for it.

Ask the same question separately about three kinds of data, because they are usually backed up by three different mechanisms, and the one that gets forgotten is almost always the second:

1. The database — orders, users, messages, everything typed in.

2. Uploaded files — product photos, ID documents, receipts, anything a user sent you.

3. Configuration and secrets — API keys, payment credentials, environment variables. Not sensitive data in the usual sense, but without them a restored database runs nothing.

One more thing worth confirming: that a copy lives somewhere other than the machine it came from, and in a different account. A backup in the same place as the original survives a disk failure but not a deleted project or a stolen password.

3. Time to restore: from "everything is gone" to "customers can log in"

A backup nobody has ever restored is not a backup. It is a hope with a filename.

This is the number nobody has, because having it requires doing the thing once. Ask for the measured time from a real drill, not the estimate. An estimate is "maybe an hour or two". A measured answer is "ninety minutes, we timed it on the fifth, here is the runbook".

If the answer is an estimate, ask for the drill. It is a half-day of work and it looks like this:

1. Create a fresh, empty environment — as if the old one no longer existed.

2. Restore last night's database backup and the uploaded files into it.

3. Put the configuration and keys back from wherever they are kept.

4. Point a test domain at it, log in as a real customer, place an order, check an image loads.

5. Write down the elapsed time and every step somebody had to ask about. That document is the runbook.

A first drill almost always finds something: a credential that only existed on one laptop, an image bucket that was never in the backup script, a DNS record with a long cache time that keeps customers pointed at a dead server for hours after you fixed everything else. Finding those on a quiet afternoon costs you a half-day. Finding them during an outage costs you the outage, twice over.

4. Who gets paged, and how they find out before your customers do

Most small products are monitored by their customers. Something breaks at 21:00, a user sends a WhatsApp message, you see it the next morning, your developer sees it an hour after that. By then the thing has been down for twelve hours and you have no idea why, because nothing was recording.

The four questions to get answered, in writing:

• What is checked, and how often? "The login page and one real API call, every minute" is a good answer. "The server responds to a ping" is not — a server can be perfectly alive and serving errors to every customer.

• Where does the alert land? A channel someone reads, plus something that makes a phone ring. Email alone is where alerts go to die.

• Who is responsible, by name, and in which hours? And who is second, when the first person is on a flight or in hospital?

• What response time is being promised, and what does "response" mean — someone has looked at it, or it is fixed?

Be realistic about the answer you can get. A two-person team cannot honestly promise fifteen minutes at 03:00 on a Sunday, and you should be suspicious of anyone who says they can without charging for a rota. What you can get is an agreed window, a named person, a channel that actually rings, and honesty about the hours outside it. An outage you know about at 07:00 with a documented restore path is a bad morning. The same outage, discovered by a customer three days later, with no runbook, is the kind of thing that ends a young product.

What good app hosting answers sound like

You are not looking for impressive numbers. You are looking for specific ones, measured rather than guessed, at a price that matches the stage you are at. For a small product with real but modest traffic, a set of answers we would be comfortable signing reads roughly like this:

• Cost: one monthly figure, itemised, with the ten-times-traffic figure beside it.

• Backup age: at most one hour for the database, at most a day for uploads, with one copy in a separate account.

• Time to restore: a measured number, a date for when it was measured, and a runbook you can open yourself.

• Paging: a check on a real user journey every minute, alerts to a channel and a phone, a named person, stated hours, a named backup.

If the answers come back as "it's on the cloud", "backups are automatic" and "we'd get it back pretty quickly", you have learned something useful, and you have learned it while the product is still small enough to fix cheaply.

What to do next

1. Send the four questions to whoever hosts your product today, in one message, and ask for written answers.

2. Decide the backup age you can live with as a business, before you hear what is currently possible. It is a commercial decision, not a technical one.

3. Book the restore drill. Put the measured time and the runbook in the same folder as your contracts.

4. Re-ask all four every time the product changes shape — a new payment provider, a new file upload, a tenfold jump in users.

If you have asked and the answers were vague, or nobody can tell you how long a restore takes, we can run the drill with your current team and write the runbook with them. Tell us what you are running and we will tell you which of the four numbers to fix first.