What Happens After Custom Software Launches, and What Maintenance Really Costs

Every conversation about commissioning custom software reaches the same objection. Who maintains it after launch, and will not maintenance quietly eat the savings you just finished calculating?

It is a fair question. The honest answer is not the one either side of the argument usually gives. Custom software does need attention. It needs far less than most people expect, the work is predictable, and almost none of it is emergency work.

Who maintains custom software after it launches?

You own it, so you decide. In practice that means one of two things: you take the code and handle it yourself or with whoever you hire, or you keep an hourly relationship with the people who built it and call them when something needs doing.

There is no third option where the software quietly stops working unless somebody keeps paying a monthly fee. That idea comes from SaaS, where access itself is the thing you are renting. A build you own keeps running on your hosting whether or not you ever speak to the builder again.

What actually needs attention after launch, and how often?

Five things, and only two of them are unpredictable. Everything else is scheduled work you can put on a calendar.

For a stable internal tool in a normal year, the honest total is hosting plus a handful of hours. Not zero. Nowhere near a subscription.

Why does custom software break less than people expect?

Because it does one job for a known set of users, and because nobody is pushing changes at it. Most of the churn people associate with business software comes from the vendor, not from the software wearing out.

A platform serving thousands of customers has to keep shipping. It redesigns the interface, deprecates an API, moves a feature you rely on into a higher tier, retires an integration. You absorb every one of those changes on the vendor's schedule. That absorption is maintenance work. You just never see it on a separate invoice, so it does not feel like maintenance. It feels like Tuesday.

A tool with twelve users and one workflow has no roadmap other than yours. Code does not rust. What genuinely moves underneath it is the dependency tree and the hosting platform, and keeping up with those is bounded, well understood work.

Will maintenance eat the savings?

No, and the gap is not close. Here is the arithmetic.

$12,000 a year of SaaS is $120,000 over ten years if the price never moves. It moves. At 5% annual escalation the same subscription costs about $151,000. A $30,000 build is $30,000 over ten years, and at the end of it you own the asset. Break-even is year 2.5. By year ten you are $90,000 to $121,000 ahead, before hosting and upkeep.

That $60,000 already carries the hosting line for the full decade. What it does not carry is hourly work you request. That distinction matters: it is work you request. A year in which you ask for nothing costs you hosting and nothing else. There is no version of a subscription that behaves that way.

What does the support model look like when there is no retainer?

Two options, and you pick.

• Take the code and owe nothing. Source in your repository, infrastructure in your cloud account, credentials in your name, documentation written for someone who was not in the room. You can hire anyone, in house or otherwise, to carry it forward. No notice period, no exit fee, no ongoing obligation.
• Hourly, priced by complexity, with severity triage. You call when you need something. You pay for the work that happens and nothing else.

There is no flat monthly retainer, because a flat monthly retainer is a subscription with extra steps. It bills the same in a month with two incidents and a month with none, which quietly recreates the exact problem you commissioned the build to escape.

Severity triage means three lanes, agreed in writing before anything goes live:

1. Production down. Nobody can work. Response starts immediately, and it displaces other scheduled work.
2. Degraded. One workflow is broken and a workaround exists. Scheduled in days, not weeks.
3. Change or enhancement. Quoted and scheduled like any small piece of project work.

Rates are quoted in writing before any work begins. There is no published rate, because complexity varies too widely for a single number to be an honest one.

How is that different from SaaS maintenance?

SaaS maintenance is real work and somebody is genuinely doing it. The difference is that it is bundled invisibly into a price that rises every year whether or not a single line of that work touched your account.

What does migrating off a SaaS platform actually involve?

Four steps, and for a typical internal tool it takes two to six weeks. Most of that elapsed time is the parallel run, not the engineering.

1. Export. Every platform exports something. Quality varies enormously. Core records usually come out clean as CSV. Attachments, uploaded files, notes, and audit history are where exports go thin. Pull a full export now, while you are still a happy customer and nobody is watching the clock.
2. Map. Decide what each record means in the new system. This is the step that takes judgment rather than time, and it is where you discover the three custom fields somebody repurposed in 2023 to mean something entirely different.
3. Run in parallel. Both systems stay live for one to two weeks. Real work goes into the new tool. The old one stays as a safety net and a reference, not as a second place to type things.
4. Cut over and archive. Downgrade the old subscription to its cheapest read-only tier for a defined window rather than deleting it on day one, then cancel. Historical data almost never needs to be live. It needs to be queryable, which is a much cheaper requirement.

The part that surprises people is how little history has to come across. Two years of active records usually covers everything anyone actually opens. The rest belongs in an archive you can search, not in the tool your crew uses every morning.

The fifteen minute standard

Nobody on your team should need more than about fifteen minutes to get set up and be productive on the new tool. If it needs a training day, the tool is wrong.

That is a design constraint, not a marketing line, and it is achievable for custom software in a way it is not for a platform. A general tool has to expose everybody's features to everybody, because the vendor cannot know which of its thousands of customers needs which screen. A tool built for one operation can show a dispatcher the dispatch screen and nothing else. There is far less to learn because there is far less that does not apply.

If a build lands and people need a manual to use it, that is a defect. It gets treated as one.

The short version

Well built custom software is not fragile. It needs patching a few times a year, a larger upgrade every year or two, hosting that runs itself, and changes when your business changes rather than when a vendor decides. You pay for the work that happens. In a quiet year, that is hosting.

If you want the numbers for your own situation, the SaaS cost calculator runs the ten year comparison against your actual spend in about a minute. If you would rather talk it through, a free teardown is thirty minutes on your real stack, tool by tool, with a straight answer on which parts are worth owning and which should stay rented. Sometimes the answer is stay on SaaS. When it is, we say so.