I get this question almost every week. Someone has a workflow that's held together by spreadsheets and WhatsApp messages, they've tried two or three SaaS tools that didn't quite fit, and now they want to know what it would cost to build their own.
My answer disappoints people more often than you'd think. Roughly half the time I tell them not to build anything.
That's not false modesty. It's that the build vs buy software decision gets framed as a technology question when it's really a business question — and when you frame it correctly, the answer is usually obvious within twenty minutes of honest conversation. Let me walk you through how I get there.
The real cost of building is not the build
When someone asks for a quote to build custom software, they're thinking about one number: the development cost. That's the smallest part of the picture.
Here's what actually shows up over three years:
- Initial build. The number you asked for. Whatever it is.
- The gap between "done" and "actually usable." Almost always 20–40% more work than the original scope, because you learn what you really needed once people start using it. This isn't bad estimation. It's how software works.
- Hosting, monitoring, backups, security patching. Small monthly numbers that never stop.
- Maintenance. Libraries go out of date. Payment gateways change their APIs. A browser update breaks a date picker. Budget 15–20% of the original build cost per year just to keep the lights on.
- Your own time. The founder or ops lead who has to specify, review, and test. This is the cost nobody puts in the spreadsheet and it's often the biggest one.
Compare that with a SaaS tool at $40 per user per month. For a 15-person team that's $7,200 a year, and someone else handles all five bullet points above. On pure cost, buying wins for a very long time.
So why does anyone build?
Four situations where building genuinely wins
In my experience, custom software makes sense in four scenarios. If you don't fall into one of them, buy.
1. The process is your competitive advantage
If the way you do something is why customers choose you, forcing it into somebody else's software is quietly dangerous. You end up reshaping your differentiator to fit a dropdown menu.
A logistics company I spoke with had a pricing model based on a combination of route density and customer volume that no freight platform supported. They'd been running it in Excel with one person as the single point of failure. That's a legitimate build — the logic is the business.
Contrast that with a company that wanted a custom accounting system because they "do invoicing differently." They didn't. They just had bad habits. Buying forced them to fix the habits, which was the actual win.
2. Integration is the whole problem
Sometimes you already own all the right tools and the pain is that they don't talk to each other. Sales data in one place, inventory in another, finance exporting CSVs at month-end.
Here the build isn't a new application — it's a thin layer that moves data between systems and gives people one screen to work from. These projects are smaller, cheaper, and have a much clearer payoff than a full platform rebuild. If you can name the three systems and the specific data that needs to move between them, you're in good shape.
3. Per-seat pricing has stopped making sense
SaaS pricing is beautiful at 10 users and painful at 400. If you're paying five figures a month for software where most users touch 10% of the features, the maths eventually flips. I'd want to see at least a two-to-three year payback before recommending it, though — and remember your headcount might shrink, not just grow.
4. You want to sell it
This is a completely different conversation. If your goal is SaaS product development — building something you'll sell to other companies — then you're not solving an internal cost problem, you're starting a new business line. Different risk profile, different funding logic, different metrics. More on that below.
The middle path most people miss
The build vs buy software framing is a false binary. There's a third option that suits a lot of businesses better than either extreme: buy the boring parts, build the sharp bit.
Nobody needs a bespoke user authentication system. Or a custom email sender, or a hand-rolled payments module, or a homegrown document storage layer. Those are solved problems with mature, cheap, well-tested services behind them.
What you might need custom is the 20% that encodes your actual process — the pricing engine, the approval workflow, the scoring logic, the report your regulator demands in a specific format.
We do this a lot. Take an existing platform, plug in proven services for the commodity functions, and spend the real engineering effort on the part that's genuinely yours. It usually cuts the build by half and dramatically reduces long-term maintenance, because most of the surface area is somebody else's problem to keep secure.
Our own Orbis Lead CRM came out of exactly this thinking. We kept seeing teams pay for enterprise CRM suites and use three screens of them, then still need custom work for their pipeline logic. So we built something focused, with room to extend where it matters. If you're a sales-driven business, that's often a better starting point than either a bloated suite or a from-scratch build.
Questions to ask before you commit
Before you sign anything — with us or anyone else — get honest answers to these:
- Have you actually tried three tools properly? Not demos. Two-week trials with real data and real users. A surprising number of "nothing fits" conclusions come from one afternoon of poking around.
- Can you write down the workflow on one page? If you can't describe it clearly to a person, no developer will get it right either. Vague requirements are the number one cause of expensive rebuilds.
- Who owns this in two years? Software needs a person inside your company who cares about it. If nobody's name goes in that box, don't build.
- What breaks if we do nothing for six more months? If the honest answer is "not much," you have a nice-to-have, not a project.
- Is the pain a software problem or a process problem? Automating a broken process just makes it break faster.
A note on AI in this decision
Right now a lot of build conversations start with "we want AI in it." Fair enough — there's real value there. But be specific. "AI-powered" isn't a feature. "Automatically extract line items from supplier PDFs so the accounts team stops typing them" is a feature, and it's the kind of thing that's genuinely cheaper to solve now than it was two years ago.
If your requirement is document processing, classification, forecasting, or natural-language search over your own data, that's often a strong case for custom work because generic SaaS can't see your data or your context. Our AI & ML development work skews heavily toward those narrow, measurable problems rather than broad platform rebuilds.
If you're building a SaaS product to sell
Quick, honest notes for anyone going down the SaaS product development route rather than solving an internal problem:
- Charge money before you build the full thing. Pre-sales beat surveys.
- Your first version should be embarrassingly narrow. One customer type, one workflow, done well.
- Budget for support, sales and onboarding from day one. The code is maybe 40% of the effort of running a SaaS business.
- Multi-tenancy, billing, and permissions are harder than they look. Get architecture decisions right early — retrofitting them is genuinely painful.
You can see the kinds of products and platforms we've shipped in our work if you want a sense of scope and style.
Where I land on build vs buy software
Buy by default. Build when the thing you're building is either the reason customers pick you, the glue between systems you already own, or a product you intend to sell. And when you do build, build less than you think — buy the commodity plumbing and put your money into the part that's actually yours.
The worst outcome isn't buying software that fits imperfectly. It's spending eight months and a serious budget building a slightly worse version of something you could have subscribed to for a few hundred dollars a month.
If you're stuck on this decision, get in touch and tell me about the workflow. I'll give you a straight answer, including "go buy this instead" if that's the right one. No pitch, no pressure — I'd rather earn work you actually need.