"You'll own it" is the best argument for building custom software and the one most likely to be oversold. Owning software is not the same as owning a filing cabinet — it needs somewhere to run, occasional attention, and a plan for the day the person who built it isn't around. None of that is expensive, but pretending it's free is how projects end up abandoned.
Here's the honest annual cost, where it goes, and what actually happens if your developer disappears.
The annual cost of running software you own
Plan for 10–20% of the build cost per year. On a $12,000 build that's $1,200–$2,400. Here's what makes it up.
| Item | Per year | What it covers |
|---|---|---|
| Hosting | $240–$1,200 | A small cloud server, managed database and backups. Most small-business apps genuinely do run on $20–$60/month of infrastructure. |
| Domain, TLS, email delivery | $20–$150 | Certificates are free now; transactional email is a few dollars a month at small volumes. |
| Security patching | $400–$1,000 | Dependency and OS updates, a few hours a quarter. The item most often skipped and the one that hurts most when it is. |
| Monitoring & backup verification | $0–$300 | Uptime checks and, critically, periodically restoring a backup to confirm it works. |
| Small changes | $500–$2,000 | A few hours here and there as the business changes. Optional in any given year, but rarely zero across three. |
| Typical total | $1,200–$2,400 | Against a subscription it replaced of $5,000–$25,000 |
Patching is the item most often left out of a plan, and the one that turns a manageable annual cost into a large modernisation project when it is skipped for a few years.
The comparison that matters: this is not "subscription versus free." It's a $10,000/year subscription versus a $1,500/year running cost after a one-off build. That's still a transformative difference — it's just not zero, and any quote implying otherwise should worry you.
Patching is not optional
The single most common failure mode for owned software isn't a catastrophic bug — it's four years of neglect. Dependencies go unsupported, the operating system falls out of security updates, and eventually a small change requires a large upgrade first. A few hours a quarter prevents this entirely; skipping it turns a $600/year cost into a $6,000 modernisation project.
If you're hosting it yourself, put it in someone's calendar. If someone hosts it for you, ask them specifically whether patching is included — the word "hosting" often means nothing more than "the server is switched on."
"What if my developer disappears?"
This is the right question and it deserves a concrete answer rather than reassurance. Whether you can survive it depends entirely on decisions made at build time.
What you need to hold, from day one
- The source code, in your own repository account. Not the developer's account with you added as a collaborator — your organisation, your billing, your ownership. A repository you can be removed from is not yours.
- Credentials for the hosting and domain in your own name, with your own payment method.
- A database backup you have personally restored. An untested backup is a rumour.
- A README that gets a new developer running locally. If a competent stranger can't start the app in an afternoon, you have a continuity problem regardless of who wrote it.
What makes handover hard
Not exotic technology so much as undocumented technology. A conventional stack — a mainstream language, a standard SQL database, containerised deployment — means any competent developer can pick it up in days. Where people get stuck is a clever custom framework nobody else knows, or a deployment that only works because of undocumented state on one server.
This is why I build on Java, Spring Boot, Angular, PostgreSQL and Docker rather than anything more interesting. The hiring pool is large and the documentation is public. Boring is a feature when the goal is that you aren't dependent on me.
A reasonable continuity test
Once a year, ask a developer who has never seen the project to clone the repository and get it running from the README alone. It costs an hour of someone's time and tells you exactly how exposed you are. If they can't, that's a documentation task, not an emergency — but only if you find out before you need to know.
Hosted versus self-hosted
Owning the code doesn't mean you have to run the servers, and for most small businesses running them yourself is the wrong use of attention.
- Let someone host it if nobody on your team wants to think about backups, certificates and patching. You still own the code and can leave whenever you like.
- Host it yourself if you already have IT capability, a regulatory reason to keep data on your own hardware, or the running costs are large enough to matter.
The decision is reversible in both directions, which is the real difference from a SaaS subscription. That's why both options are offered rather than one being bundled in.
The honest summary
Owning custom software costs a low four figures a year and requires that somebody, at some point, thinks about it. In exchange you get a bill that doesn't grow with headcount, software shaped to your business, and the ability to change vendors without changing systems.
For a business paying five figures a year for a tool that doesn't quite fit, that trade is usually obvious. For a business paying $200 a month for something that works, it isn't — and that's what the break-even calculator is for. Put the running cost in it honestly; leaving that field at zero produces an answer that isn't true.