What Happens After Launch: The Real Cost of Owning Custom Software
If you're wondering what custom software actually costs after launch, plan on 15% to 25% of your original build cost every year in hosting, security patches, dependency updates, and monitoring — before you touch a single new feature. At Schkovl, we treat post-launch ownership as a predictable line item we discuss before you sign, not a surprise your team discovers six months in. It's the part of the custom software conversation most agencies skip during the sales process.
What Does "Owning" Software Actually Mean After Launch?
Launch day feels like the finish line. It isn't. Software is closer to a building than a product you buy off a shelf: the moment it's occupied, it needs a roof check, a working furnace, and someone who answers the phone when a pipe bursts.
Owning custom software means someone is responsible for four ongoing jobs: keeping it running, keeping it secure, keeping it compatible with everything it talks to, and keeping it observable enough that you find out about problems before your customers do.
If we covered your build cost already and you're past that stage, this is the article about what comes next.
What Are the Real Categories of Post-Launch Cost?
Maintenance isn't one line item. It's five distinct categories, and each one fails differently if it's ignored.
| Category | What It Actually Covers |
|---|---|
| Hosting & infrastructure | Servers, databases, storage, CDN, and the scaling costs that grow with real usage |
| Security patches & dependency updates | Framework, library, and runtime updates that close known vulnerabilities before they're exploited |
| Third-party API drift | Payment processors, mapping services, and integrations that change their contracts without asking permission |
| Monitoring & uptime | Error tracking, performance alerts, and the on-call response when something breaks at 2 a.m. |
| Bug fixes | Correcting real defects in existing functionality — distinct from building anything new |
None of these show up as a feature you can demo. All five show up as a business risk if nobody owns them.
How Much Should You Actually Budget Each Year?
Our custom software cost breakdown mentioned the 15% to 20% annual maintenance rule in passing. Here's what that actually looks like by project type.
MVPs and simple internal tools: $3,000 – $9,000 per year. Mostly hosting, dependency updates, and a monitoring baseline. Bug volume is usually low because scope is small.
Multi-tenant SaaS platforms: $15,000 – $45,000+ per year. Infrastructure costs scale with real tenant usage, and security patching carries more weight because customer data is at stake.
AI agent systems: $8,000 – $30,000+ per year. Model API pricing changes, prompt behavior drifts as underlying models update, and guardrails need periodic re-testing against new failure modes.
These are ongoing ranges, not one-time fees folded into your original quote. If your agency's proposal doesn't mention a number in this territory, ask why.
Why Do Businesses Get Blindsided by These Costs?
The sales conversation ends at launch. Agencies are incentivized to close the build contract. Ongoing costs make the initial number look bigger, so they often get mentioned only if you ask directly.
Code doesn't stay still even when you don't touch it. Dependencies your software relies on get updated, deprecated, or found to have security flaws. A codebase that isn't maintained doesn't stay working — it slowly becomes a liability.
The people who built it can disappear. A freelancer moves on. An agency shuts down. Without documented access — hosting credentials, repository ownership, deployment pipelines — a working piece of software can become unreachable to its own owner.
What's the Difference Between Maintenance and Product Evolution?
These get budgeted together constantly, and they shouldn't be.
Maintenance keeps what already exists working: patches, updates, monitoring, bug fixes. It's defensive spending. Skipping it doesn't save money — it defers a bill that arrives later with interest, usually as an outage or a breach.
Product evolution is new features, redesigns, and scaling work. It's offensive spending, tied to growth, and it's the budget line most businesses actually want to talk about.
Fund both, separately. A business that only budgets for evolution eventually builds new features on top of an unpatched foundation.
How Do You Plan for This Before You Sign a Contract?
Ask who owns what after launch. Source code, hosting accounts, domain, and deployment credentials should belong to you, documented in writing, not held by a single person's personal account.
Get a maintenance SLA in writing. Response time for a critical bug should be hours, not "whenever someone's free." Get that number before launch, not after the first outage.
Budget the line item on day one. Treat the 15% to 25% annual range as part of the original decision to build, not a renegotiation six months later.
Confirm your exit terms. Ask what happens if you want to move to a different team. If the answer is vague, that's the answer.
At Schkovl, this is part of the same Gap Analysis we run before any build: we scope what launch costs and what owning it costs for the next three years, so the number you agree to is the number you actually pay.