6 min read
What happens after launch
What "we run it" means in practice, what to expect in the first ninety days, the questions to ask a team about maintenance before you sign, and an honest comparison of managed cloud against a VPS.
By Nexar Labs
- Operations
- Cloud
- Founders
The build is nearly finished and the conversation has turned to "support". You are being offered a monthly retainer, or a handover, or both, and you are not sure what either includes. This post sets out what running software actually involves for a small team, so you can judge what you are being offered and what you would be taking on yourself.
Our own answer on the home page is short: launch is the start, and we either stay on for monitoring, maintenance and the next set of features, or hand over with documentation and a runbook. Here is the long version.
What "we run it" has to include
Running software is a list of chores that nobody sees until one is missed. Any offer to "run it" should cover all of the following; if one is absent, ask who is doing it.
| Chore | What it means in practice | How often |
|---|---|---|
| Monitoring | Uptime checks from outside, error tracking inside, and a dashboard that shows requests, errors and latency | Continuous |
| Alerts | A named person is paged when the site is down or errors spike, with a threshold that does not cry wolf | Continuous |
| Backups and restore tests | Automated database backups, kept off the production server, and a restore actually performed to check they work | Daily backup; restore test quarterly |
| Dependency updates | Security patches to the framework, libraries and operating system, applied and deployed | Weekly review, urgent patches within days |
| Cost review | Someone reads the cloud bill, spots the thing that doubled, and turns off what nobody uses | Monthly |
| Incident process | What happens when it breaks: who is told, who fixes it, and a short written account afterwards | Per incident |
| Runbooks | Written steps for the ten things that will happen: deploy, roll back, rotate a secret, restore a backup, add a domain | Kept current |
The restore test deserves its own sentence. A backup is a file that exists; a restore is proof that it works. Most teams have the first. Ask for the date of the last restore.
On-call for a team of three
Large companies have rotas and follow-the-sun coverage. A small product does not, and pretending otherwise leads to promises that fail on the first bank holiday.
What is realistic: a response commitment during working hours, an out-of-hours alert that goes to a phone for outages only (not for every error), and a written expectation of how long a fix might take. What is not realistic: a guaranteed fifteen-minute response at 3am from a two-person team for the price of a retainer. If someone offers that, ask how.
The honest version for most early products is that an outage at 3am is noticed by an uptime check, the alert wakes someone, and they either restart the thing or decide it can wait until morning. For a booking tool with fifty users that is the right trade. For a payment system it is not, and the difference should be priced.
The first ninety days
Expect the following, roughly in order.
Weeks one and two. Things that never happened in testing happen: an email lands in spam, a user's browser is older than anyone thought, a form accepts something it should not. This is normal and it is why the team that built it should still be on hand. Fixes are small and frequent.
Weeks three to six. The first real usage pattern appears. One page is slower than expected because real data is bigger than test data. The cloud bill has a line nobody predicted. This is when the first cost review and the first performance fix happen.
Weeks six to twelve. The product is quiet, and the danger is that quiet gets mistaken for finished. Dependencies fall behind, the backup job fails silently, and the "we'll set up monitoring properly later" item is still open. The first ninety days should end with every chore in the table above owned and scheduled.
Budget for this. A reasonable rule is that the first three months after launch need a fraction of the build team's time every week, not none of it. [NEEDS: the typical share of build-team time Nexar Labs allocates for the first three months, or the shape of its standard support arrangement, so this can be a number.]
Questions to ask before you sign
Whether you are buying a retainer or planning a handover, ask these and write the answers into the contract.
- What is monitored, and where can I see it? You should be able to open the dashboard yourself.
- Who gets the alert, and what is the response commitment in and out of hours?
- Where are backups stored, how long are they kept, and when was the last restore tested?
- How are security updates handled, and how fast is a critical patch deployed?
- What does the monthly infrastructure bill look like, and who reviews it?
- What is in the runbook, and can I read it now? If it does not exist yet, when will it?
- If we part ways, what do I receive? The answer should be: the repository, the cloud account, the domain, the runbook, and a walkthrough, all already in your name.
- What is the notice period, in both directions?
An agency that has run products will answer these quickly. One that has only built them will have to think, and you will hear the difference.
Managed cloud or a VPS
This is the question we get asked most after launch, and the answer on our FAQ still stands: it depends on what the product needs. Here is the trade-off in more detail.
Managed cloud (AWS and similar). You pay for services that do the chores: a managed database with automated backups and failover, object storage that does not fill up, a load balancer that handles certificates, a queue that just works. The bill is higher and less predictable, and it grows with usage. In return the operational load drops and the product can scale, integrate with a wider ecosystem and meet compliance requirements without re-platforming. It is the right choice when any of those three is on the horizon, and when a startup credit programme is paying the first year.
A well-run VPS. One or two servers at a fixed monthly price. Cost is predictable and low, and for a small workload the performance is often better than the equivalent cloud spend. The chores do not go away; they land on you or your team: operating-system patches, database backups you configure and test yourself, certificate renewal, disk space, and the day the provider reboots the host. "Well-run" is doing a lot of work in that sentence. A VPS with nobody maintaining it is the most expensive option of all, paid for at 3am.
A rough rule: if the product has one server's worth of load, no compliance requirement and a team that can patch a Linux box, a VPS is sensible and the money goes further. If it has customers who ask about data residency, a traffic pattern with spikes, or nobody who wants to be the person who patches the box, use managed services and spend the saved time on the product. Either way, the backups still need a restore test.
The handover, if you are taking it in-house
If the plan is for your own team to run it, insist on receiving: access to every account as owner, a runbook that a new engineer can follow without calling anyone, a written list of the recurring chores with their current owner set to "you", and a period of overlap where the original team is reachable. Two weeks of overlap is common; a month is better for anything with payments.
What to do next
If your product is about to launch and nobody has answered the eight questions above, send us the answers you have and the gaps through the contact form. We reply within two working days with the chores we would put in place first, whether or not we are the ones running it.