Web development · 5 min read
Build or buy: when off-the-shelf software stops being cheaper
The licence fee is the visible cost. The workarounds are the expensive one. A practical way to decide whether to keep paying for software that nearly fits, or build the thing that does.
Every growing business hits the same moment. The tool that ran the whole operation for two years starts to feel like it is running the operation into a wall. Someone suggests building something custom. Someone else points out that the subscription is only $79 a month and building sounds expensive. Both people are looking at the wrong number.
We get asked to settle this argument regularly, usually by an owner who already suspects the answer and wants a second opinion. So here is how we actually think about it, without the sales pitch.
The subscription is rarely the real cost
Off-the-shelf software is cheap to buy and expensive to bend. The licence fee is visible and small. The costs that hurt are invisible and spread across your team.
- The manual step someone does every day because the tool cannot do it. Twenty minutes a day is roughly two full working weeks a year, per person.
- The second tool you bought to cover a gap in the first one, plus the third one that stitches them together.
- The data that lives in three places and never quite agrees, so someone reconciles it by hand before every management meeting.
- The per-seat pricing that quietly triples the moment you hire.
- The workflow you shaped around the software instead of around how your business actually works.
None of that shows up on the invoice. All of it shows up in payroll.
Four signs you have outgrown the tool
1. Your process lives in a spreadsheet next to the software
When there is a shadow spreadsheet doing the part the tool cannot, the tool is no longer the system of record. It is one input among several, and the spreadsheet is where the real work happens.
2. You are paying for a platform to use a tenth of it
Big platforms price for the whole feature set. If you use inventory but not the CRM, the marketing suite or the reporting module, you are subsidising other people's use cases.
3. Every new hire needs a week of training on your workarounds
Training on software is normal. Training on the specific sequence of clicks your team invented to get around a limitation is a maintenance cost with no owner.
4. The thing that makes you different is the thing the tool handles worst
This is the strongest signal of all. If your competitive edge is the part you are fighting the software to support, generic software is capping the thing you are best at.
A rough way to compare the two
| Factor | Off the shelf | Custom build |
|---|---|---|
| Upfront cost | Low, often just a trial | Meaningful, paid once |
| Ongoing cost | Per seat, rises as you grow | Hosting plus occasional changes |
| Time to first use | Same day | Weeks |
| Fits your process | You fit its process | It fits yours |
| Cost of a new requirement | Wait, or work around it | Scoped and built |
| If the vendor changes direction | You absorb it | Not your problem |
| Who owns the data | Them, on their terms | You |
When off-the-shelf is still the right answer
Most of the time, honestly. We turn down custom builds fairly often, and we would rather say so early than take the work and watch it disappoint.
- The problem is genuinely standard. Accounting, payroll and email are solved. Do not rebuild them.
- You are still figuring out the process. Custom software is expensive to change while you are changing your mind. Use a flexible tool until the shape settles.
- The tool does 90 percent and the last 10 percent is an annoyance, not a bottleneck.
- You have no appetite for owning anything. Custom software is an asset, and assets need an owner.
What building actually looks like
The word custom makes people picture a two year project and a seven figure budget. That is enterprise software, and it is not what most businesses need. What we usually build is narrow and specific: one workflow, done properly, connected to the tools you are keeping.
A quoting tool that produces your quotes in your format in ninety seconds. A booking flow that understands your actual availability rules. An internal dashboard that pulls three systems into one screen so nobody reconciles anything by hand again. Small surface, large effect. You can see the sort of work we take on in custom web applications.
The honest test
Take the number of hours your team spends every week working around your current software. Multiply it by their hourly cost, then by fifty. If that number makes you wince, you are already paying for a custom build. You are just paying it in salaries instead of owning anything at the end.
If the number is small, keep the subscription and get on with your work. That is a perfectly good outcome, and it is the one we recommend more often than not.
Questions people also ask
Is custom software always more expensive than a subscription?
Upfront, almost always. Over three to five years it often is not, because the subscription grows with headcount while a build is paid once and then maintained. The deciding factor is usually how much manual work the off-the-shelf tool forces on your team.
How long does a custom build take?
A focused, single-workflow tool is typically a matter of weeks rather than months. Long timelines usually mean the scope was never narrowed, which is a scoping problem rather than a technical one.
What happens if our needs change after we build?
That is the advantage of owning it. Changes are scoped and built rather than requested from a vendor and waited on. Budget for occasional changes the same way you would budget for a subscription.
Can we build part of it and keep our existing tools?
Yes, and this is what we recommend most often. Keep accounting, email and anything else that is genuinely standard, and build only the part that is specific to how you work.
