Custom software is priced like a purchase and behaves like a lease. Every system sits on a stack of things that change without asking permission: platform interfaces, browser behavior, tax and rate rules, an accounting package’s annual update, and the staff who knew how it worked. The question is never whether a system will need attention. It is who is on the hook when it does, and whether that was agreed before the first outage or during it.
The assumptions that make a build feel finished
It is working gets confused with nothing has changed around it
A system that has run untouched for months is not proof of durability. It is proof that none of its dependencies have changed yet. The interval between changes on somebody else’s schedule is not yours to control, and quiet periods predict nothing.
The first outage is also the first conversation about who fixes it
Nobody discusses response expectations while a project is going well. The discussion happens the morning something stops working, with the business waiting, and it starts from nothing. Whatever gets agreed under that pressure is worse for both sides.
Small changes have no cheap path
Somebody needs a field added or a form condition changed. With no arrangement in place, that request has to be quoted, scheduled, and started cold, which makes a small change uneconomic. Requests accumulate until there are enough to justify a project.
Documentation was written for the handover, not for month six
Handover documents describe how the system works. What is needed later is why it works that way: which decisions were deliberate, which constraints came from a connected system, and which oddity is load-bearing. That knowledge decays faster than code.
Nobody owns the boundary between the system and the systems around it
Internal staff own what is inside the application. Vendors own their own platforms. The integration between them belongs to whoever built it, and after a one-time engagement that is nobody. Failures cluster there, because that is where outside change arrives.
Life after launch under each model
This is the honest version of what happens next. The last column is worth reading closely, because it describes the outcome when neither model is chosen, which is the most common arrangement of all.
| What happens after launch | Under a one-time build | Under managed support | What it costs you when nobody owns it |
|---|---|---|---|
| A connected platform changes its interface and the integration stops | You find out when somebody notices data stopped moving | Monitored, and usually corrected before staff see a backlog | Silent gaps until somebody notices, plus a manual catch-up |
| A defect surfaces that testing did not catch | A fresh engagement, scoped and scheduled from a cold start | Handled by people who still hold the context | The workaround becomes permanent and the process reverts to manual |
| Somebody needs a field added or a form condition changed | Bundled with other requests until there is enough for a project | A small change, done in sequence, with no scoping exercise | Staff keep a shadow spreadsheet for what the system cannot do |
| The person who understood the system leaves | Whatever was written down is what remains | Context sits with the builder as well as your staff | Every future change begins with an expensive rediscovery phase |
| Credentials, certificates, or tokens expire | It works until the day it does not, with no warning | Tracked with expiry dates and rotated ahead of the date | A hard outage on a date that was knowable months in advance |
| Usage grows past what the original design assumed | Performance degrades and gets reported as a bug | Watched, with a conversation before it becomes urgent | The system gets a name for being slow and people route around it |
| A rate, rule, or regulation the logic depends on changes | You have to notice it, then commission the change | Raised as a change and scheduled against the effective date | Transactions processed on rules that no longer apply |
| Security patching of the platform underneath | Depends on who hosts it and whether they tell you | Part of the arrangement, on a stated cadence | Exposure that stays invisible until it is not |
| The business itself changes how it works | The system slowly stops matching reality | Change is expected and budgeted, so the system tracks the business | A system nobody uses and a process gone back to email |
Deciding which model your build actually needs
Count your external dependencies honestly
List every third party the system talks to: the payment processor, the email service, the accounting package, the identity provider, the hosting platform. Each will change something on a schedule you do not set. The count is the best single predictor of how much attention a system needs.
Ask what a week without it would cost
Not what it would feel like, what it would cost. Whether invoices go out, whether crews get dispatched, whether customers can be served. That answer sets the response time you should pay for. A system whose absence is an inconvenience and one whose absence stops revenue deserve different arrangements.
Name the internal owner, and be honest about their capacity
Some businesses genuinely have somebody who can read logs, rotate a credential, and talk to a platform’s support. If that person exists, has time, and is not the operations manager doing it after hours, a one-time build with good documentation is a real option. If naming them requires a pause, that is the answer.
Separate keeping it running from changing it
These are four distinct things: fixing breakage caused by external change, fixing defects in the original build, making small changes, and adding capability. Arrangements that do not distinguish them produce disputes about what is included. Price and scope each one.
Write down what supported means before signing anything
Response time during business hours, what counts as an incident versus a change, how much change is included, who holds the credentials, where the code lives, and how you leave. The last two matter most. An arrangement you cannot exit is not support.
What ongoing ownership usually covers
- custom application development — The build side of the decision, and the choices during a build that reduce how much attention it needs later.
- systems we have built — Systems where the integration surface, rather than the application itself, is what needs an owner.
Is this a fit for your business?
A good fit when
- The system connects to platforms owned by other companies that update on their own schedule
- Money, payroll, or compliance depends on the system running when it should
- Nobody on staff can be named as the person who would investigate an outage
- The business is still changing how it works, so the system must change with it
Probably not a fit when
- The tool is self-contained, used by one team, and a few days without it is an inconvenience
- You have technical staff with real capacity, so buy documentation and access instead
- The build has not started and support is being sold before the scope exists
What to have ready
- The list of external services the system will depend on
- An honest answer about what happens operationally on a day it is unavailable
- The name of the person who would field the first call, or that there is none
Questions we get asked
Can we do a one-time build and add support later?
Yes, and it is a reasonable way to start. Expect a cold start: after a gap, whoever picks it up has to rebuild context that would otherwise have been continuous, and that is chargeable time before any work happens. The gap is also when documentation goes stale.
What should a support arrangement actually include?
At minimum: monitoring that tells somebody before your staff notice, a stated response time during business hours, correction of breakage caused by external change, credential and certificate management, and an allowance of small changes. It should not quietly include new capability.
Who should own the code and the data?
You should, and this is worth being firm about at contract stage rather than at exit. That means the source in a repository you control, credentials in your accounts, hosting in your name where practical, and a tested export path for the data. None of it is unusual to ask for.
We have an in-house developer. Does that change the answer?
It changes it if their responsibilities include this system and not only their existing work. A developer who inherits an unfamiliar system alongside a full workload will keep it alive and will not have time to improve it. What tends to work is your developer owning the application and an outside party owning the integrations.
Is hosting the same as support?
No, and the two get conflated regularly. A hosting provider keeps a server running and patches the operating system. Nobody there is watching whether your integration stopped moving data last Thursday, or will fix your form when a connected platform changes a field. Hosting is a component of support, not a substitute.
Related
Tell us what the process looks like now and we will map what a system would need to do. No obligation, and you keep the map either way.
