A two-person team running a scheduling app found out on a Tuesday that a migration script had wiped every customer’s time zone setting. Their backups were fine, technically. Nightly snapshots, kept for thirty days, exactly as configured on launch day.
The restore took eleven hours. Nobody had ever run one, and the snapshot came back as a whole separate database they had to compare against production by hand, row by row, while support tickets piled up.
That same month, the founder noticed her biggest customer was costing her more than they paid.
Backups Fail at the Restore
A snapshot proves you saved data. It says nothing about whether you can get the right piece of it back, quickly, without breaking anything else.
Most of the best practices for AWS around data protection point to the same habit: rehearse recovery. Turn on point-in-time recovery for your database so you can roll back to 9:14 a.m. instead of last midnight. Then schedule a real restore every quarter, into a fresh instance, with a stopwatch running. Write down every step that surprised you.
The first drill usually exposes something dull. An environment variable pointing at the wrong host. A permissions gap that only the departed contractor knew how to fix. A restore that works for the database but forgets the uploaded files sitting in object storage.
Partial restores deserve their own plan. Customers rarely need the whole system rolled back. They need one account, or one table, as it looked yesterday. Keep a script ready that restores a snapshot to a scratch instance and exports only what you need.
Separate Accounts, Separate Keys
One leaked admin key can delete production and every backup sitting beside it. This happens more often than teams admit, sometimes through an attacker and sometimes through a cleanup script with too much reach.
Copy backups into a second account that production can write to but never delete from. Add retention locks so even an administrator can’t purge them early. Cross-region copies cost extra, and for a small product with modest uptime promises, they can wait. The separate account can’t.
Pricing When Every Request Has a Cost
Back to that expensive customer. The app had added an AI assistant that summarized meeting notes, and the pricing page promised unlimited use on the top plan. One client pasted in two-hour transcripts several hundred times a week.
Flat plans work when your marginal cost per user is close to zero. Language model features break that assumption. Each request burns tokens, and the bill arrives whether or not the customer’s subscription covers it.
Pure token-based pricing solves the margin problem and creates a different one. Buyers don’t think in tokens, and finance teams hate invoices they can’t forecast. A procurement manager will not approve a line item that reads “variable, depends on usage.”
The hybrid approach holds up better. Include a monthly allowance in each plan, express it in units customers understand, such as summaries or documents, and charge for overage at a published rate. Show a usage meter inside the app so nobody gets surprised at renewal. Translating token-based pricing into plain units takes some testing, but you only have to get the conversion roughly right and adjust it as model costs drop.
Know Your Cost per Customer
None of this pricing work holds up if you can’t see what each tenant costs. Tag resources by customer where the architecture allows, and track model usage per account in your own database rather than reconstructing it from the monthly cloud bill.
Watch the quiet line items too. Snapshot storage grows every month you keep old copies. Log retention defaults are often generous. Data transfer out of the cloud surprises nearly everyone the first time a big customer exports their history.
Set budget alerts at 50, 80, and 100 percent of what you expect to spend. They’re free.
Questions Worth Asking Before Launch Day
The scheduling team’s two problems looked unrelated, one technical and one commercial. Both came from settings chosen once and never questioned. Restoring a time zone and repricing an AI feature are easy to fix in a quiet week, and miserable to fix in a bad one.
