Who maintains it when you leave? The custom-software question you're right to ask.

The best question we get in a sales call is also the one lazy agencies fumble. An owner who has been burned before leans forward and asks some version of: what happens to this thing when you disappear? Who maintains it when you leave? It is the right question. It is asked too rarely, and answered honestly even less.

Every town has a graveyard of orphaned custom software. The booking tool the owner's nephew built before he moved to Austin. The 'CRM' a freelancer shipped in 2019 that nobody can deploy anymore because the one server it ran on died. The dispatch board that works fine until the morning it doesn't, and the only person who understood it stopped returning emails. If you have heard those stories, your instinct to be careful is correct. The rest of this post is about turning that instinct into specific questions, because the fear is right but the conclusion most owners draw from it (just buy SaaS, never build) is wrong.

What actually breaks when the builder leaves

Here is the part almost nobody tells you: the code is rarely the problem. Code sits in a file and does exactly what it did yesterday. It does not rot on its own. What rots is everything around the code that lived in one person's head and never got written down.

• The decisions, not the code. Why does the invoice round this way? Why does an emergency job skip the normal queue? The code shows what happens; it almost never shows why. When the builder leaves and takes the why with them, the next person is afraid to touch anything, and fear is how a working tool slowly freezes into a museum piece.
• The infrastructure nobody can see. A tool is not just its code. It is the server it runs on, the database it talks to, the domain, the API keys, the cron job that emails the Monday report. If those live in the builder's personal accounts instead of yours, the day they leave is the day you get locked out of your own software.
• The clever parts. A junior builder reaches for the clever trick because it feels impressive. A senior one reaches for the boring, obvious version because they have been the person inheriting someone else's cleverness at 11pm. Clever code is job security for the person who wrote it and a liability for everyone after.

Notice that none of these are really about custom versus off-the-shelf. They are about whether the thing was built to be handed over or built to be owned forever by one person. That is a choice the builder makes, and you can check for it before you sign anything.

The SaaS you trust has the same problem. You just can't see it.

Owners ask 'who maintains my custom tool when the agency leaves' and almost never ask the mirror-image question about the SaaS they already depend on. What happens when the vendor gets acquired and sunsets the plan you are on? When they triple the price at renewal because they know switching costs you three weeks? When they quietly deprecate the one integration your whole workflow hangs on, and your answer is to wait on a support queue?

You have lived through at least one of these. The difference is that with SaaS you never had the option to maintain it yourself, because you never had the code. 'Who maintains it' is a real risk for both. With software you own, at least one of the answers is 'you can, or anyone you hire can.' With software you rent, the only answer is 'the vendor, on the vendor's terms, for as long as the vendor feels like it.'

Build for handoff on day one, or don't start

The maintenance question is not something you settle after launch. It is decided by a hundred small choices made before the first line of code. Here is what 'built to be handed over' actually looks like, and what to insist on.

• Boring, standard technology. The tool should be built in a language and framework a competent developer anywhere can read on their first day, not the builder's favorite niche stack. Boring tech is not a lack of skill. It is the skill. It means the pool of people who can maintain this is thousands deep instead of one.
• Everything in your accounts, not ours. The code lives in a repository you own. It deploys to hosting you pay for under your own login. The domain, the database, the API keys: all in accounts with your name on them. A good builder sets this up on day one and adds themselves as a guest, not the other way around. If you can be locked out, you do not own your software. You are renting it from your own contractor.
• Documentation as a deliverable, not a favor. A short, plain-English README: how to run it, how to deploy it, where the secrets live, and why the three weirdest decisions were made. Not a hundred-page manual nobody reads. One page that turns a panicked afternoon into a calm one. Put it in the contract as a deliverable so it actually gets written.
• No proprietary lock-in to the builder. Be suspicious of any agency that hosts your tool only on their platform, hides the source, or charges a fee you cannot stop paying without the whole thing going dark. That is not a maintenance plan. That is a hostage situation with a nicer invoice.
• Tests on the parts that matter. You do not need 100% test coverage on an internal tool. You need automated checks on the handful of things that would quietly cost you money if they broke: the pricing math, the lead routing, the place that touches payments. Tests are how the next maintainer changes code without being afraid of it.

The three honest ways to answer 'who maintains it'

There are exactly three real answers, and a tool built the right way keeps all three doors open. A tool built the wrong way closes all of them.

1. You maintain it. For a lot of internal tools this is genuinely fine. If it is built on boring tech and documented, a small business with even one semi-technical person, or a freelancer on call, can keep a stable tool running for years. Stable software needs far less attention than people expect. It is not a truck. It does not need an oil change every quarter.
2. We maintain it, on a light retainer. Often the right answer for the first year or two, while the tool is still changing. The key word is light. If your maintenance retainer costs as much as the SaaS you replaced, something has gone wrong: either the tool is doing too much or the agency is padding. Maintenance on a well-built tool is occasional, not constant.
3. Anyone competent can pick it up. This is the one that makes the other two safe. Because the tool is boring, owned by you, and documented, you are never trapped with us. If we get hit by a bus, get too expensive, or just get worse, you hand the repository to the next developer and they are productive in a week. The ability to fire your builder without losing your software is the whole point.

The trap is an agency that can only offer option two, because they built it so that options one and three are impossible. Then the retainer is not a service. It is the rent on a building you thought you bought.

Questions to ask before you commission anything

Whether you build with us or with anyone else, take these to the first conversation. The answers tell you more about the builder than any portfolio.

1. 'Whose accounts will the code, hosting, and domain live in?' The only acceptable answer is yours. Anything else, walk.
2. 'What happens to this if our relationship ends?' A good builder has a clean answer ready and is not offended you asked. A bad one gets vague or defensive. That tells you everything.
3. 'What is it built in, and how many developers could maintain it?' You are listening for boring and many, not cutting-edge and few.
4. 'What documentation do we get, and is it in the contract?' If it is a deliverable, it gets written. If it is a verbal promise, it does not.
5. 'What does a realistic year of maintenance actually cost and involve?' A builder who has shipped real tools can answer honestly. One who waves the question away either has not done it or is hiding the bill.

Five questions, ten minutes. They will keep you out of the orphaned-tool graveyard more reliably than any reference call.

The bottom line

The fear behind 'who maintains it when you leave' is healthy, and the agencies that deserve your trust are the ones that take the question seriously instead of waving it off. But the conclusion to draw is not 'never build.' It is 'only build with people who build for handoff.' Custom software you own, on boring tech, in your accounts, with one page of docs, is one of the few business assets that genuinely cannot be taken away from you, repriced out from under you, or sunset by someone in another time zone. That is more than you can say for most of the SaaS on your invoice.

When we scope a custom build, the handoff plan is part of the quote, not an upsell after it. If you want a straight answer about what owning a tool would actually commit you to, our custom-software practice will walk you through it, maintenance math included, before you spend a dollar on code.