We build custom software for a living, so read this with that bias declared. The strongest argument against our own pitch happens to be true: custom software is not free after the build. You stop paying a vendor and start paying yourself, hosting, maintenance engineering, security patching, evolution. Ownership is a subscription too; the difference is who sets the terms. This is the honest ledger we wish more agencies published, including the cases where SaaS simply wins.
Is custom software really free once it is built?
No. Building custom removes the licence line from your budget, not the recurring cost. Software that is used keeps changing, dependencies age, regulations shift, users ask for more, and change costs engineering time every single year. The real comparison is never subscription versus free; it is a vendor's subscription versus a subscription to yourself.
Anyone who quotes you a build price with a zero next to year two is either inexperienced or hoping you will not ask. The moment software has users, it has a pulse: monitoring, patching, small fixes, occasional features. The useful question is what that pulse costs, what it buys, and how it compares, honestly, in both directions, with the SaaS bill it would replace. That comparison is the core of any sane build-versus-buy decision, and it is where Build vs Buy: When to Use SaaS and When to Build Custom Software starts as well.
What belongs on the honest year-two ledger of owned software?
Six categories cover most of it: hosting and infrastructure; maintenance engineering; security patching and dependency upgrades; monitoring and incident response; evolution work; and knowledge continuity. A commonly cited planning heuristic puts annual upkeep somewhere around fifteen to twenty-five percent of build cost, treat that strictly as a placeholder until your own measurements replace it.
- ▸Hosting and infrastructure. Compute, storage, backups, TLS, DNS, log retention. Usually the smallest category at SME scale, and the easiest to price from real invoices.
- ▸Maintenance engineering. Small fixes, user requests, data corrections, the steady heartbeat cost that never fully stops.
- ▸Security patching and upgrades. Dependency updates, framework majors, periodic review. Skipping this converts a budget line into an incident.
- ▸Monitoring and incident response. Either someone gets paged, or nobody does and outages last longer.
- ▸Evolution. The features you will want in year two. Not optional if the software is core to the business.
- ▸Knowledge continuity. Documentation, handover, and keeping the bus factor above one.
The discipline is the same one we recommend for technical debt: run it like a ledger, not a landfill, named categories, measured quarterly, no folklore.
When does SaaS genuinely win?
SaaS wins when the problem is undifferentiated, when the vendor's scale funds security and features you could never staff alone, and when your usage maps cleanly to the pricing model. Email, payroll, accounting, video calls, CRM for a five-person sales team: renting is rational there, and building would be self-indulgent.
- ▸Commodity workflows. If a thousand companies need exactly what you need, the vendor amortizes the engineering across all of them and you cannot beat that economics.
- ▸Vendor-scale security and compliance. A major SaaS vendor's security team is larger than most SMEs' entire headcount; for some workloads that is the product.
- ▸No ownership capacity. If nobody in your organization can own a system, not build it, own it, custom becomes an orphan, and an orphaned system is the most expensive way to store business data.
- ▸Fast-moving domains. Where the vendor's roadmap is the feature, renting keeps you current without paying for the R and D yourself.
When does ownership actually pay back?
Ownership pays when the workflow is core to how you make money, when per-seat or usage pricing scales against your growth, when the vendor's roadmap diverges from yours, or when data control is strategic. In those cases the self-subscription buys equity: every year of upkeep compounds into an asset you keep.
The seat arithmetic is often the tipping point: when a dashboard is read by everyone in the company, per-viewer pricing turns your growth into the vendor's revenue, the calculation we walk through in Custom Dashboards vs Power BI and Tableau: The Seat Math. For EU organizations there is a second, quieter driver: control over where data lives and under whose law, the argument of Renting Software Is Renting Sovereignty. And ownership has an option value even before you exercise it, a credible partial build changes renewal negotiations, as we show in Build the Exit Before the Renewal.
How do you compare a SaaS bill and an ownership budget fairly?
Compare three-to-five-year totals on both sides, not this month's invoice against a build quote. The SaaS side includes subscriptions, seat growth, renewal increases, integration and workaround labor, and eventual exit cost. The ownership side includes the build amortized over its life plus the full recurring ledger above. Most comparisons cheat exactly one side.
The two common cheats: the SaaS column omits the humans, the admins, the spreadsheet glue around the tool's gaps, the integration upkeep, and assumes renewal prices stay flat, which public reporting on vendor pricing suggests is optimistic; verify against your own contracts and current vendor terms. The ownership column omits upkeep entirely or assumes the first build is the last. For realistic build-side inputs, start from How Much Does It Cost to Build Custom Software in 2026?, and remember that an underpriced build inflates every later year, the trap detailed in The Hidden Costs of Cheap Software Development.
What makes the self-subscription flat, and what makes it explode?
Year two is mostly decided in year one. Boring architecture, few dependencies, tests, CI, and one documented deployment path keep the self-subscription flat. Exotic stacks, microservices for a five-person company, unreviewed AI-generated code, and single-person knowledge make it explode. Ownership cost is a design outcome, not a lottery.
- ▸Flatteners: a mainstream stack your local market can hire for, a small curated dependency tree, tests that make upgrades safe, and documentation that survives staff changes.
- ▸Exploders: novelty-driven stack choices, premature distribution, and code nobody reviewed at merge time.
The extreme case of the exploding self-subscription is the unreviewed AI-generated tool that quietly became load-bearing, we price that failure mode category by category in The Year-Two Bill: What AI-Generated Internal Tools Really Cost.
How should you decide? A five-question test
Ask: Is this workflow differentiating? Does the pricing scale against us? Can we name the engineer who will own it? Can we export our data today? Would we rebuild this tool if it vanished tomorrow? Mostly yes points to build; mostly no points to rent; a mixed sheet points to a hybrid.
The hybrid deserves more attention than it gets: keep the commodity core rented and own only the differentiating edge, so the SaaS remains the system of record while a custom layer owns the workflow where you actually compete, the pattern we detail in Replace the Seat, Not the Suite. If the sheet points to a full migration instead, stage it properly rather than heroically: Escaping SaaS: The Complete Guide to Migrating to Custom Software is the runbook-level version of that plan.
How TuniCyberLabs helps
Our discovery engagements sometimes end with a written recommendation to keep the SaaS, that outcome costs us a project and earns us a client, which is the trade we prefer. When we do propose a build, the proposal includes the year-two ledger: maintenance, hosting, patching, and evolution priced next to the build itself, so the subscription to yourself is signed with open eyes. Our services page shows how those engagements are structured.
Want the two-sided ledger for your own stack? Ask us for the comparison worksheet, we will fill in both columns with you.