The cost of software after launch: what nobody budgets for

Most companies budget a software project the way they'd budget a purchase: a price, paid, and then it's yours and done. Software doesn't work like that. It is closer to a building than a product — it is yours once it's built, and like a building it needs upkeep, or it degrades. The launch is not the finish line; it's the start of the part nobody budgeted for. This guide is the honest version of that ongoing cost: where it comes from, what it realistically runs, and how to plan for it before it becomes a surprise.

Why software is never finished

A piece of software does not exist in isolation. It sits on top of an operating system, a browser, a runtime, dozens of libraries, a hosting platform, and a set of third-party services — and every one of those moves underneath it. A browser updates and changes a behaviour. A new iOS or Android version ships and an app that worked yesterday breaks. A library you depend on has a security flaw disclosed. None of that is a defect in your software; it is the ground shifting under it. "Maintenance" is mostly the work of keeping a stationary thing standing while everything it rests on moves.

Where the ongoing cost actually comes from

The annual cost is not one line; it is five, and naming them is the first step to budgeting honestly.

• Dependency and security patching · every library your software uses is a potential vulnerability the day a flaw is disclosed. Staying patched is continuous, non-optional work — and the alternative is an accumulating security debt.
• Platform and OS changes · new iOS and Android releases, browser changes, framework major versions. Each can break something, and each arrives on someone else's schedule, not yours.
• Hosting and infrastructure · servers, databases, bandwidth, the AI inference or third-party API calls if your product uses them. A real recurring bill that scales with usage.
• Real-world bug fixes · no test suite catches everything. Real users find the edge cases, and the fixes are maintenance whether you planned for them or not.
• Small changes · a tax rate changes, a partner's API updates, a logo needs swapping, a regulation shifts. Individually tiny, collectively a steady stream.

A realistic maintenance budget

There is no universal number, but a widely used rule of thumb puts annual maintenance at roughly 15–25% of the original build cost. A €40k build, then, carries something like €6–10k a year to keep healthy. Treat that as a planning anchor, not a quote — the real figure moves with the stack and the surface area. A mobile app tends toward the higher end, because it lives at the mercy of two app stores and two OS release cycles. A simple marketing site sits lower. A product with heavy third-party integrations sits higher, because every integration is a dependency that can change.

Keep maintenance and new features separate

A common and costly mistake is running maintenance and new-feature work out of one undifferentiated budget. When they share a pot, the visible, exciting work — new features — wins every prioritisation call, and the invisible work — patching, upkeep — gets deferred until it becomes a crisis. Budget them as two separate lines. "Keep it alive and secure" is a fixed, non-negotiable cost. "Make it do more" is a discretionary investment you size to your roadmap. Mixing them means the discretionary work silently eats the non-negotiable work.

What a clean handover saves you

Maintenance cost is not fixed by the laws of physics — it is heavily influenced by how the software was built and handed over. The same feature set costs far less to maintain when it ships with an automated test suite (so a dependency update can be verified in minutes, not feared), current documentation (so whoever maintains it isn't reverse-engineering intent), a working CI/CD pipeline (so a patch deploys safely), and clean, readable code. A studio that hands over a keys-in-hand project with all of that has lowered your maintenance bill for years. One that hands over a tangle has raised it. This is a real reason the build decision and the maintenance cost are linked — and a reason to ask about the handover before you sign.

How to cover it: retainer, ad-hoc, or in-house

Three models cover ongoing maintenance, and the right one depends on scale.

1. A retainer · a fixed monthly arrangement with the studio that built it or another team — predictable cost, the maintainers already know the code, and security patching happens without you chasing it. The simplest fit for most small and mid-size products.
2. Ad-hoc · you call someone when something breaks. Cheaper in a quiet month, but patching tends to slip because nothing is scheduled, and the team is re-learning the code each time. Workable for very stable, low-surface software.
3. In-house · a permanent engineer or team. Right once the product is large and central enough to justify a full-time hire — and at that point maintenance and new features are usually one continuous effort anyway.

How DField Solutions handles it

We build so the maintenance bill is low by default — an automated test suite, current documentation, a working CI/CD pipeline, and a keys-in-hand handover, so whoever maintains the software (us or anyone else) starts from a clean base. After launch you choose: a retainer with us, where patching and upkeep are handled on a predictable monthly cost, or a clean exit where you take the fully documented project to your own team or another developer. There is no licence fee and no lock-in either way — what changes is only who does the upkeep, never whether you can.

If you're scoping a build and want the total cost of ownership on the table — not just the build price — the pricing page covers the tiers including retainers, and a 30-minute discovery call is the place to talk through what your specific product will cost to keep healthy. The services overview covers what we build.