Working together · 6 min read
What happens after launch: running software you own
Published 8 September 2026 · Updated 16 September 2026 · By Sam Fourie, Niddo
Launch is the start of the useful part. Software you own needs three things afterwards: someone watching it (monitoring, alerts, backups), someone maintaining it (dependency updates, security patches, small fixes), and someone improving it from what users do. Budget roughly ten to twenty percent of the build cost per year for the first two, and decide deliberately who does the third.
The first thirty days
Real users find what tests cannot. The first month needs a team on call for fixes within hours, an eye on the one metric the product was built to move, and a tightening of monitoring as real traffic shows where the alerts should be. This is the period a warranty covers, and it should be planned, not hoped for.
Watching it
- Error monitoring (Sentry or similar) with alerts to a person, not a mailbox.
- Uptime checks on the pages and jobs that matter, with a runbook for what to do when they fail.
- Backups that are restored on a schedule to prove they work, not just taken.
- A monthly look at cost: hosting, database, third-party usage. Small products drift.
Maintaining it
- Framework and dependency updates, monthly, with the test suite as the safety net.
- Security patches when they land, not at the next quarterly review.
- Domains, certificates, API keys and vendor plans renewed before they lapse.
- Small fixes and quality-of-life changes batched into regular releases.
Improving it
The backlog after launch should come from what users do, not from the original wish list. Ship in small releases, measure, and keep a short list of the next three things. Products die from either neglect or feature creep; a steady release rhythm avoids both.
Three ways to run it
| Model | Fits when | Watch for |
|---|---|---|
| Your own team | You have engineers and the product is core to the business | Handover quality: docs, runbooks, tests, everything in your accounts |
| A studio retainer | You want the builders to keep building and no in-house team yet | A clear scope for the retainer and a documented exit at any time |
| Hybrid | Your team runs it, the studio is on call for changes and upgrades | Agreed response times and who owns deployments |
What it costs
Infrastructure for a product at MVP scale is usually $30 to $300 a month, plus usage-based services such as payments, email and storage. Maintenance and small improvements typically run ten to twenty percent of the build cost per year, as a retainer or as your team's time. Larger improvements are scoped and priced as their own builds.
What a proper handover includes
- Repositories, cloud accounts, domains and third-party services in your name, with you as owner.
- Environment variables and secrets documented and stored where your team can reach them.
- A README that gets a new engineer running locally in an hour, and a runbook for deployments, backups and incidents.
- The test suite and continuous integration, green.
- An architecture note: what talks to what, and the decisions behind it.
How Niddo runs it
Run is the fifth step in how we work: hosting, updates, monitoring and support, quietly handled on a retainer, or a documented handover to your team. Either way you own everything from day one. Ask us about running your product.
Questions
People also ask.
What does software maintenance cost?
Plan for ten to twenty percent of the original build cost per year, plus infrastructure and usage-based services. Regulated or integration-heavy products sit at the top of that range.
What if we want to stop working with the studio?
You own the code, the accounts and the documentation, so you can hand it to your own team or another studio at any time. A good handover is designed for exactly that.
Do we need a retainer?
Not if you have engineers who can own it. If you do not, a small retainer is far cheaper than discovering an outage or an expired certificate the hard way.
How often should dependencies be updated?
Monthly as a rhythm, immediately for security patches, with automated tests run before every release.