You do not need a dev team to own your software
The usual objection to owning the system you run is that a roofing company has nobody to maintain it. What you actually hold is a standard artifact any competent developer can pick up, and most weeks it needs nobody at all.
The objection is fair and it comes up in most conversations. A roofing company has an office manager, some estimators and crews. Nobody there is going to maintain software.
The answer is that owning a system does not mean employing the people who built it. What you hold is a standard artifact, deliberately built out of ordinary parts, and in a normal week it asks nothing of anybody. We have covered why ownership matters separately, in owning your software instead of renting it. This is about the practical question underneath it.
What you hold
Ownership here is not a feeling or a license term. It is a specific set of things, and it is worth knowing the list so you can check you have them.
The source code, in a repository under an account you control. Not shared with you. Yours, with the builder as a collaborator you can remove.
The infrastructure, running in a cloud account in your company's name with your billing attached. This is the one most often got wrong, because it is easier for a builder to run everything in their own account and hand you a login. That is a hosting arrangement, not ownership, and the distinction becomes visible at exactly the wrong moment.
The database, and with it the data, in a standard format that standard tools can read.
The deployment documentation: how it gets from the repository to running, what environment variables exist, where the secrets live. This is the part that determines whether a new developer needs a week or an afternoon.
And every credential, held by you, including the ones for whatever third-party services it calls.
If all five are yours, a person leaving changes nothing structural. If any of them are not, you have something that behaves like ownership until it is tested.
What maintenance is
Software that is running and not being changed is not a garden. It does not grow weeds on its own.
The recurring work comes in three shapes. None is daily.
Dependency updates are the routine one. Libraries underneath any application get security patches, and applying them is a small, well-understood job a few times a year.
Somebody else's change is the one with teeth in this industry. If your system calls a measurement provider's API or your accounting software's, those vendors occasionally change something, and good ones publish it in advance. This is the only upkeep with a real deadline attached, so it is worth knowing which of your connections would bite.
Then there are changes you ask for. Those are not maintenance at all. They are the business wanting something new, at whatever pace you choose.
The three arrangements
The first is a light retainer with whoever built it. Predictable, and they already know the system. It is the easiest option and the least independent, and it stays reasonable as long as the five things above are genuinely in your name, because that is what keeps it a choice.
The second is an independent developer engaged when there is work. This covers a fourteen-person roofing company comfortably, and such people are easier to find than owners expect. A competent generalist can take on a documented application built with ordinary tools, and the work arrives in small pieces instead of as a full-time role.
The third is hiring somebody. That makes sense once a company wants changes continuously instead of occasionally. Few roofing companies are there, and the ones that are know it already.
What we have seen is that owners overestimate the first option's necessity and underestimate the second's availability. The instinct is that specialized software needs the original authors. That is only true when the thing was built in an unusual way.
Why boring technology is the whole answer
This is where the risk sits, and it is worth being blunt.
A system built on a widely used language, a standard relational database and mainstream hosting can be picked up by a large number of people. A system built on something clever and rare cannot, and the smaller that pool is, the more you are depending on specific individuals no matter what the contract says.
The temptation to be clever is real, and it serves the builder more than the owner. Interesting technology is more fun to write and produces a better story. Ordinary technology produces an application any developer can read on a Tuesday.
For a roofing company, the correct instinct is to ask for the least interesting version of everything. It is also cheapest to change later.
Check it before you rely on it
There is a test that settles this in about an hour, and it can be run before anything is handed over.
Give a developer who has never seen the system read access to the repository and the deployment documentation. Ask them two questions: what does this do, and what would it take to change this one thing. Pay them for the hour.
If they can answer both, the handover is real. If they cannot, you have found out at the only point where it is cheap to fix, which is before you depend on it.
That test is worth writing into the arrangement in advance, because it converts ownership from an assurance into something checked.
Frequently asked questions
Who maintains software a roofing company owns?
Most weeks, nobody. Working software that is not being changed does not require attention. The real work is occasional: dependency updates, a change when a connected vendor alters an API, and whatever the business asks for next.
Do I have to hire a developer?
Not in most cases. The three arrangements that work are a light retainer with whoever built it, an independent developer engaged for occasional work, or a staff hire once the company is large enough to want changes continuously. The middle option covers most roofing companies.
What exactly do I own at handover?
The source code in a repository under your account, the infrastructure running in an account in your name, the database and its data, the deployment documentation, and every credential. If any of those sit with the builder, you have a dependency rather than ownership.
Is it risky if the people who built it disappear?
Only if the system was built on unusual technology. This is the argument for boring choices: a standard language, a standard database and standard hosting mean the pool of people who can pick it up is large. Exotic choices are where the real risk lives.
How would I know whether a developer could pick it up?
Ask one. Give a developer read access and the deployment documentation and ask them to describe what it does and what changing one thing would take. An hour of somebody's time buys you a genuine answer before you rely on it.
Keep reading
