Subscribing is cheaper in year one and more expensive forever. Building is the reverse. The break-even for a well-scoped build usually lands somewhere in year three, and by year five a build is commonly 30% to 60% cheaper in total cost of ownership, because the subscription line never stops and the build's does.
The numbers under that: companies now spend roughly $10,800 per employee per year on software subscriptions, up from $9,643 the previous year. Smaller and mid-sized companies average about $11,200 per employee. For a fifty-person business that is $560,000 a year. And around 49% of licences go unused.
Skip to: what you are actually spending · the $250,000 number that misleads everyone · the break-even · which one you should pick
What you are actually spending
Most owners can name their three biggest subscriptions and are wrong about the total, because the total is not three subscriptions. It is three big ones plus fourteen small ones bought by four different people over six years, several of which renew on cards nobody checks.
| Team size | At ~$11,200 per employee / year |
|---|---|
| 5 | $56,000 |
| 10 | $112,000 |
| 25 | $280,000 |
| 50 | $560,000 |
Source: 2026 published software-spend benchmarks. Averages across many industries, so treat as an order of magnitude and then go count your own.
The number that should actually annoy you is the 49% of licences that go unused. That is not a rounding error. On a $112,000 spend, unused seats are plausibly tens of thousands of dollars a year buying nothing at all.
Do this before anything else, and it is free: export the last twelve months of card and bank statements, filter for anything recurring, and list every one with its monthly cost and who uses it. Most people find between three and eight things nobody has opened in a year. Cancelling those is the highest return per hour available to you, and it requires building nothing.
The $250,000 number that misleads every small business
Search what custom software costs and you will be told around $250,000 for a typical project. That figure is real, and it is why most owners conclude that building is for companies with a procurement department.
It is also measuring something you are probably not buying. That number reflects enterprise development: multi-team projects, long discovery phases, compliance regimes, integration with systems that predate the people maintaining them.
A single tool that replaces one workflow, for one small team, scoped tightly and shipped in weeks, is a different category of purchase. The confusion between those two things is the single most expensive misunderstanding in small business software, because it keeps people subscribing to nine tools out of a belief that the alternative starts at a quarter of a million dollars.
The question is never "can I afford custom software". It is "what is the smallest thing I could build that removes the most expensive recurring problem", and then whether that specific thing beats what it replaces.
The break-even, plainly
| Subscribing | Building | |
|---|---|---|
| Year 1 | Clearly cheaper | Costs more, up front |
| Year 3 | Roughly level, as subscription costs accumulate | |
| Year 5+ | Keeps rising, and rises with headcount | Commonly 30% to 60% cheaper in total |
Source: published 2026 total-cost-of-ownership comparisons. The shape is consistent across analyses; the exact crossover moves with scope and team size.
Two details decide where your crossover really lands.
Per-seat pricing is the compounding one. Subscription cost usually scales with headcount. A build's cost does not. If you plan to grow, that difference widens every year, and it is the single strongest argument for building.
Maintenance is real and gets left out. Software you own needs hosting, updates and occasional fixes. Anyone comparing a build against subscriptions without a maintenance line is selling you something. Include it and the comparison still usually works, but it works honestly.
Which one you should actually pick
Keep subscribing when
- Your process is a standard one, and the tool was built for exactly it. Accounting, payroll and email are solved. Do not rebuild solved things.
- The tool is genuinely used by the people paying for it.
- You are still figuring out the process. Never build a workflow you have not run manually.
- The total is small enough that the effort is better spent elsewhere.
Build when
- You are paying for four tools to do one job, plus a spreadsheet holding them together, plus a person whose job is partly that spreadsheet.
- The way you work is the advantage, and every tool makes you work its way instead of yours.
- Your cost rises every time you hire, for software your new hire barely touches.
- The integration you need does not exist, and the workaround is a person retyping things between two screens.
The last one is worth pricing properly. Someone spending two hours a day moving data between systems is roughly a quarter of a salary, every year, forever. That is usually a larger number than the build it would take to end it.
Questions people ask
How much does a small custom build actually cost?
Far less than the headline enterprise figure, if it is scoped to one workflow rather than a whole department. Ours are fixed price, quoted before anything starts, in tiers rather than hourly, so the number does not move once agreed. The honest answer for any provider is that it depends on scope, and anyone quoting before understanding your workflow is guessing.
What happens when it needs changing?
Everything needs changing. Budget for it explicitly rather than discovering it. Ask any provider what a change costs and how quickly it happens, before you start, and get the answer in writing.
Is it not risky to depend on one small provider?
It is a fair concern and worth asking directly. Ask where it is hosted, what happens if you part ways, and how you would get a copy of your data. Those are reasonable questions with concrete answers, and a provider who is vague about them is telling you something.
How long does a small build take?
Weeks rather than months for one well-scoped workflow. Longer when several systems have to agree with each other. Anyone promising a full replacement of your stack in an afternoon has not asked enough questions.
Can I do part of this myself?
Yes, and you should start there. Cancel what nobody uses, then write down the one process that costs you the most time. That document is most of the work, and it is worth doing whether you build anything or not.
Want the math run on your actual stack?
Tell us the workflow that costs you the most time and what you currently pay to hold it together. We will tell you whether building beats subscribing for it, including when it does not. Fixed price if it does, and a straight answer if it does not.