Most build-versus-buy arguments get settled by whoever talks longest in the meeting. That is an expensive way to allocate a budget, because the decision has a real structure and the answer is usually obvious within an hour. Here is the uncomfortable part, written by a company that builds custom software for a living: for most of what you need, you should not hire us. Buy it, then spend what you saved on the one or two systems that are genuinely yours.
Start from a default: subscribe unless you can name the reason not to
Buy by default. Build only when you can state the reason in one sentence that would survive a skeptical CFO. If the reason is "the current tool is annoying" or "it would be nicer if", that is a configuration problem, a training problem, or a vendor problem. None of those get solved by writing code.
Defaults matter because momentum is expensive to reverse. Building by default accumulates systems nobody wants to own. Buying by default accumulates subscriptions, a cheaper mistake to unwind, right up until it is not. The rest of this piece is about spotting that moment early.
- ▸A good build reason is durable: still true in three years, at triple the volume.
- ▸A good build reason is specific: it names a workflow, a data model, or a cost curve, not a feeling.
- ▸A bad build reason is a bad implementation: most "our CRM does not fit our process" complaints are an unconfigured tool plus an unwritten process.
Where SaaS genuinely wins, and it wins more often than we would like
SaaS wins wherever the workflow is commodity, the compliance surface changes faster than you can track, or the vendor roadmap moves faster than any team you could staff. Payroll, accounting, email, identity, payments, e-signature, helpdesk, HR records: buy every one of them. You will not out-engineer a vendor with two hundred engineers on a problem you would assign to one.
- ▸Commodity workflow. If competitors do it the same way you do, it is not differentiation, it is plumbing. Nobody wins a market because their expense approval screen is bespoke.
- ▸Compliance-heavy domains. Payroll tax tables, VAT rules, e-invoicing mandates and accounting standards change on schedules set by governments, not by you. Buying means somebody else absorbs that regulatory churn as part of the subscription, which is the most underrated line item in SaaS pricing.
- ▸Roadmap velocity you cannot match. In fast-moving categories the vendor ships features you had not thought to ask for. Building here means racing a treadmill.
- ▸Liability and audit transfer. Certifications, penetration tests, uptime commitments and breach obligations sit with the vendor. Rebuilding that posture in-house is a security program, not a feature.
Be honest here. Much of the "our business is different" conviction inside growing companies is founder attachment rather than economics. We say so in first meetings, it costs us deals, and it saves clients from learning the same thing expensively.
Four signals that custom actually pays
Build when at least two of these signals are strong, not one. A single signal in isolation is usually solvable with configuration, an integration, or a better contract. Two or more together mean the SaaS is structurally wrong for your shape of business, and no amount of vendor negotiation will fix that.
- ▸Core workflow differentiation. The process is how you win, not just how you operate. If your margin, delivery speed or customer experience comes from doing this step differently, generic software averages you back toward the market.
- ▸Per-seat pain. Headcount grows faster than the value each additional user extracts from the tool. The most common signal, and the easiest to quantify.
- ▸Integration gravity. You are paying humans to move data between tools, or maintaining connectors that break quietly.
- ▸Data ownership. Your most valuable asset lives in a schema you cannot query, cannot export in a useful shape, and cannot use for analysis or AI without paying again.
Two strong signals is a serious conversation. Three is a build. We covered the general version in Build vs Buy: When to Use SaaS and When to Build Custom Software.
The per-seat trap, and the arithmetic that exposes it
Per-seat pricing punishes exactly the thing you are trying to do, which is grow. It is priced for the intense daily user, then charged for the supervisor who logs in twice a week to approve something. The trap is not the unit price. It is that price scales on headcount while value scales on usage.
Run this on a whiteboard with your own numbers, not ours:
- ▸Take your annual cost for one tool. Multiply by three years, then add the renewal uplift you have actually experienced, not the one written into the original contract.
- ▸Split your user list into daily power users, weekly participants and occasional approvers. Ask what each group genuinely does in the tool.
- ▸Ask what it would cost to build only the screens the occasional group needs, leaving power users on the SaaS.
That last question is the whole game, and it usually produces a far smaller number than a full replacement. It is the pattern in Replace the Seat, Not the Suite: The Partial-Build Pattern That Kills Per-Seat Pricing. You are not replacing a product, you are removing a tail of low-value seats from a pricing model never designed for them.
Integration gravity and who actually owns your data
Integration gravity is the effort your business spends keeping tools in agreement: staff copying between systems, brittle automations, nightly syncs that fail silently, a monthly reconciliation nobody enjoys. When that effort exceeds the cost of a single system of record, the economics have already flipped and the invoice will never tell you.
Data ownership is the quieter signal. Ask three questions of every core vendor:
- ▸Can you export everything, including history, relationships and attachments, in a format you could actually load elsewhere? Not a CSV of the main table. Everything.
- ▸Can you query your own data without the vendor reporting module or a per-user analytics licence?
- ▸If you left in ninety days, what would break, and who knows how to rebuild it?
If those answers are uncomfortable you have a lock-in problem, not a software problem. Audit it with The CRM Exit-Readiness Audit: Lock-In Mechanisms Hiding in Your SaaS Contract before your next renewal, while you still have leverage.
The hybrid pattern most growing companies should land on
The right answer is almost never all-SaaS or all-custom. It is a hybrid: buy the edges, build the middle. Keep vendors for commodity functions where their scale beats yours, build a thin operational core owning your differentiated workflow and canonical data, then integrate deliberately, in one direction, with one system holding the truth.
- ▸A custom operational core that owns your entities, your process states and your business rules.
- ▸Bought tools at the boundary for accounting, payroll, email, marketing automation and support, each integrated to the core rather than to each other.
- ▸One system of record per concept. Two systems that both believe they own "customer" will diverge, and you will pay a person to referee.
Hybrid is unglamorous and it is correct. It fails in one specific way worth naming: build the core but never retire the shadow processes in spreadsheets and inboxes, and you now have three systems instead of two. Migration finishes when the old habits stop, not when the software ships.
The honest year-two cost of both options
Both cost more in year two than the brochure suggests. SaaS rises through renewal uplift, seat creep, add-on modules that used to be included, and integration maintenance you absorb quietly. Custom costs through dependency upgrades, hosting, security patching, a backlog that never empties, and the risk that one person holds all the context.
Budget a custom system as a real annual line, not a rounding error:
- ▸Maintenance and dependency upgrades. Frameworks and runtimes move whether you do or not. Skipping this is how a two-year-old system becomes a rewrite.
- ▸Hosting, backups and monitoring. Small, never zero, and a backup you have never restored is not a backup.
- ▸Change work. Your business changes and the software follows. This is the largest line and the one most often forgotten at signature.
- ▸Bus factor. At least two people must be able to deploy and debug it. If your build partner is the only one who can, you swapped SaaS lock-in for vendor lock-in with worse economics.
We set out that ledger in Custom Software Is Also a Subscription, to Yourself: The Honest Year-Two Ledger. Compare like for like: three-year total cost of ownership on both sides, including the labour cost of workarounds you tolerate today. For the build side, How Much Does It Cost to Build Custom Software in 2026? breaks down what drives the number.
A decision procedure you can run this week
Do not commission a study. Score the four signals from zero to three, honestly, with the people who do the work rather than the people who buy the software. Then write three-year total cost of ownership for both paths on one page, same assumptions, including staff hours spent today on workarounds.
- ▸Score under four: stay on SaaS and fix the configuration. Renegotiate at renewal with a documented alternative in hand.
- ▸Score four to seven: build one narrow slice, keep the vendor for the rest, measure for a quarter before extending.
- ▸Score eight or more: commit to a core build with a phased migration and a written retirement date for the old system.
The only genuinely wrong move is deciding by anecdote. Whichever way it goes, write down the reason, because in eighteen months somebody will ask why.
How TuniCyberLabs helps
We run this assessment as a short paid engagement and deliver the recommendation even when it is "keep your SaaS and renegotiate". When a build is justified, our engineering teams in Tunisia and Cyprus deliver it under EU contracts, with documented handover and code you own outright. Our services page sets out scope and engagement models.
Tell us which tool hurts and what the invoice says, and we will tell you honestly whether it is worth building.