The admission a dev studio isn't supposed to make
I run engineering at a studio that makes its money building custom systems, and I say this in client meetings most weeks: most of the time, off-the-shelf is the right call.
Not out of modesty. A client we built something unnecessary for won't come back, won't refer us, and will pay to maintain software that a $60/month product would have handled better. A custom project that fails costs us both.
The question isn't "which is better". It's whether the gap between what you need and what exists is wide enough to justify building.
The test: three questions
1. Is your process your competitive advantage?
If you manage customers, send invoices and track tasks, you're doing what every business does — and there are dozens of excellent products for it. A generic process doesn't justify development.
But if you have a way of working that's the reason customers choose you — a pricing model you invented, a production process you do differently, scheduling logic no product understands — off-the-shelf forces you into its template and effectively deletes that advantage.
2. How many separate systems are you already running?
This is the most reliable signal I know. A business with a CRM, a spreadsheet for inventory, a separate time-tracking tool, and someone copying between them twice a week is already paying the cost of custom development — in hours and errors instead of an invoice.
Four or more systems with manual copying between them is usually the tipping point.
3. Are you forced to work incorrectly because of the software?
If you hear "we put it in the notes field because there's no proper field for it" or "we create a duplicate customer to work around it", the system doesn't fit. The only question left is how much those workarounds cost.
The real five-year cost
Comparing a licence fee to a build price is the wrong comparison. Here's the calculation I ask clients to run.
Off-the-shelf
| Item | Note |
|---|---|
| Monthly licensing | Usually per seat — grows as your team grows |
| Implementation | One-off, sometimes substantial |
| Add-ons and modules | The feature you need is usually on the expensive tier |
| Manual workarounds | Monthly staff hours — the hidden line item |
| Price increases | The vendor raises prices and you're already committed |
Custom
| Item | Note |
|---|---|
| Initial build | From $18,000 for a full business system |
| Infrastructure | Servers and database — usually low hundreds monthly |
| Maintenance | Not optional. Budget for it |
| Changes and additions | They will come. Always |
| Vendor risk | What happens if the studio disappears? (see below) |
The structural difference: with off-the-shelf you pay forever and it scales with headcount. With custom you pay up front and maintenance is comparatively low. Break-even usually lands somewhere between two and four years — but it moves dramatically with team size.
The third option, which is usually right
This is what I recommend most often and what fewest people consider: off-the-shelf for the generic core, custom development only for the unique part, integrated together.
For example: keep the commercial CRM for customers and invoicing — it works, there's no reason to rebuild it — and develop only your proprietary pricing engine, connected to it via API.
That typically costs a third to a half of a full build, and you get the unique advantage without maintaining a re-creation of what already exists. If you're also considering an AI layer, this is exactly the pattern described in our piece on AI agents for business.
Two recurring mistakes
"Let's build everything from scratch so it's exactly right"
This is how projects become year-long megaprojects serving a process that changed in the meantime. Always build the module with the fastest payback first, run it, and learn — the same logic as the MVP approach.
"Let's keep customising the off-the-shelf system until it fits"
There's a point where customisation costs exceed build costs, and you're left with a system that's hard to upgrade because every vendor update breaks something. If you're paying a customisation consultant on a standing basis, run the numbers.
Before you sign for a custom build
- Who owns the code? Our answer is the client, from day one. If the answer is vague, that's information.
- What happens if we change vendors? A documented system in standard technologies is one another developer can pick up. A system written "in our proprietary way" is not.
- What's in version one? A quote that's a single number for the whole project hides risk. Ask for a staged breakdown.
Bottom line
Off-the-shelf until it genuinely gets in the way. Custom when your process is the advantage, when you're running four systems in parallel, or when the software forces you to work wrong. And in between — the third option, which is usually the best value.
Further reading: the SaaS development guide and AI agents for business. Want to talk through your case? See our SaaS and business systems service or get in touch — even if the conclusion is that you shouldn't build.
Written by Evyatar Adler, CTO at FlowDev.
