Technology decisions
Custom build or off-the-shelf SaaS?
Total cost, lock-in risk, and time to value compared. The decision framework for European companies choosing between building and buying.
TL;DR
- SaaS is almost always the right choice for non-core workflows: HR, accounting, email, CRM. The question only gets hard when the workflow is core to how you compete.
- Custom build costs more upfront (€20k to €200k depending on scope) but removes per-seat fees and vendor lock-in. The payback window is typically two to four years.
- Lock-in is the underweighted risk. Switching costs, data portability limits, and vendor pricing changes at renewal are where SaaS total cost of ownership often surprises.
- The build-vs-buy decision should start with a vendor evaluation, not a development brief. Most companies custom-build what they could have bought, and vice versa.
- See how we run vendor evaluations and technology strategy for European companies.
The real question behind build vs buy
The question is not cost. It is whether the workflow is <em>core or commodity</em>.
Most build-vs-buy decisions are framed wrong from the start. The default question is "what is cheaper?" when the real question is: is this workflow something where differentiation creates commercial advantage, or is it a commodity function that any vendor can handle adequately?
**If the workflow is commodity, buy.** Accounting, payroll, email, video conferencing, project management: these are functions where SaaS vendors have invested millions and where the marginal cost to you is a monthly subscription. Building your own payroll system in 2026 is not a competitive decision. It is a distraction.
If the workflow is where your company actually competes, buying a generic solution means giving up the differentiation that makes you worth choosing. An insurance company that competes on claims processing speed should not be running a generic claims management SaaS built for the median customer. The lock-in risk from the SaaS also compounds: when the vendor raises prices at renewal, you have no leverage and no exit.
Side-by-side comparison
Total cost of ownership over a three-year horizon.
| Dimension | SaaS (off-the-shelf) | Custom build |
|---|---|---|
| Upfront cost | €0–€5k (setup, onboarding) | €20k–€200k (design, build, test) |
| Year 1 cost (typical) | €10k–€80k/year in subscriptions | €30k–€250k including build |
| Year 3 total cost | Often higher than expected due to seat growth and price hikes | Usually lower once build cost is amortised |
| Time to value | 2–8 weeks | 3–9 months |
| Vendor lock-in | High; data portability often limited | None; you own the code and data |
| Customisation | Limited to vendor roadmap | Full control; built for your workflow |
| Maintenance burden | Handled by vendor | Yours to maintain and update |
| Compliance (GDPR) | Depends on vendor residency | Full control over data residency |
| Best fit | Commodity workflows, fast start | Core workflows, competitive differentiation |
Decision signals
Which way the evidence usually points.
01
Buy when the workflow is not where you compete
HR, accounting, CRM, project management, email marketing: these are categories where a SaaS vendor has 10,000 customers funding the product roadmap you need. Buying means lower upfront cost, faster deployment, and ongoing improvements funded by the vendor. The only discipline required is vendor evaluation: not all SaaS is equal on data portability, pricing stability, and support quality.
02
Build when differentiation is the point
If the workflow is what separates you from competitors, a generic SaaS gives your competitors the same tool at the same cost. Custom build lets you encode your specific business logic, your compliance requirements, and your user experience in a system that competitors cannot replicate by signing up for the same subscription. The cost is real. So is the advantage.
03
Evaluate lock-in before signing any multi-year SaaS contract
The questions to ask before signing: Can you export all your data in a standard format? What happens to pricing at renewal if you have 50 users instead of 10? What is the vendor process for shutting down or being acquired? Lock-in is not just about moving away from a tool. It is about what happens to your negotiating position when you no longer have a credible exit.
04
Consider a hybrid: SaaS core with custom integration layer
Many of the best outcomes are not pure build or pure buy. A company might run Salesforce as the CRM core but build a custom integration layer that connects it to a proprietary quoting engine. This captures the commodity benefit of a well-supported SaaS while preserving the differentiated logic in code the company owns. Integration complexity is real, but it is often cheaper than building a full CRM from scratch.
Common questions
What decision-makers ask when the brief says "build or buy."
Is it always cheaper to buy SaaS than to build?
In year one, almost always. Over three to five years, it depends on seat growth and vendor pricing changes. SaaS subscription costs compound: a tool that costs €20k per year at 20 users often costs €80k per year at 100 users. Custom builds absorb that growth without incremental per-seat cost. The crossover point varies, but it is usually between two and four years for tools with significant user count.
How do I evaluate vendor lock-in before committing?
Ask for a data export in your evaluation. If the vendor cannot show you a clear, complete data export in a standard format during the sales process, that is a signal. Also review the contract terms for auto-renewal, price increase caps, and data deletion on cancellation. Lock-in is most painful when you are trying to leave, not when you are starting.
What does custom software typically cost to build in Germany?
A focused internal tool (one workflow, 5 to 20 users) typically costs €20k to €60k to build. A customer-facing application with more complex logic costs €60k to €200k. These are rough ranges and depend heavily on the complexity of the business logic, integration requirements, and the team doing the work. Ongoing maintenance typically runs 15 to 25 percent of the build cost per year.
What happens when a SaaS vendor is acquired or shuts down?
Data portability terms in your contract determine your options. If the contract is silent on this (many are), you depend on the acquiring company or the shutdown timeline to export cleanly. The mitigation is to run regular data exports regardless of contract terms, and to treat any SaaS where export is difficult as a vendor risk item in your technology risk register.
Should I evaluate SaaS before deciding to build?
Yes, always. Custom build decisions made without a vendor evaluation almost always overpay. A two-week vendor evaluation process costs a fraction of a build and often reveals that a SaaS tool covers 80 to 90 percent of the requirement at a fraction of the cost. The remaining 10 to 20 percent gap often motivates an integration layer, not a full custom build.
How we approach this at SomeTech.work
We run vendor evaluations before we scope any build.
When a client comes to us with a build brief, our first step is to test whether SaaS solves it first. We run structured vendor evaluations: define requirements, evaluate two to four candidates, score against a defined rubric, and produce a written recommendation. **If a vendor covers the need adequately, we say so and do not take the build revenue.** See how we approach strategy and advisory work including build-vs-buy decisions.
When custom build is the right answer, we scope it tightly: a specific workflow, a named lead, a clear integration surface with the rest of the stack. We do not scope "platform" projects with open-ended roadmaps. The discipline keeps cost predictable and prevents the build from expanding into the commodity territory it was supposed to avoid.
Concrete solution
Bring the operational risk.You get a clear diagnosis and a concrete next step.
We are the right fit if you want a team that pushes back when it matters. See outcomes and metrics →
Reviewing first?
Company evidenceon the site.
Engagements with commercial outcomes on Work. Team bios and operating model on About. Nothing to download. Review it before you commit to a call. Open to review. Commit when ready.