Technology decisions
Custom software or SaaS?
A build-versus-buy method using the same requirements, evidence, decision horizon, operating ownership, and exit test for every option.
TL;DR
- Decide one capability at a time. A CRM, proprietary quoting engine, identity service, and reporting layer can have different answers inside the same system.
- Compare equal requirements and acceptance cases. The UK Government Technology Code of Practice is public-sector guidance, but its lifecycle questions are useful beyond government: user need, integration, security, privacy, data, purchasing, and sustainability.
- Keep more than two options alive. Buy, build, hybrid, partner, defer, and stop should remain credible until disqualifiers and evidence remove them.
- Model scenarios instead of using a market-average table. The UK choosing-technology guidance calls out total cost, integration, data control, cyber obligations, reuse, and the risk of long supplier contracts.
- Test ownership and exit. A vendor still leaves configuration, access, adoption, and contract decisions with the customer. A custom build creates software delivery, security, support, and continuity responsibilities.
Start at the right altitude
Choose the decision unit before comparing solutions.
“Replace the platform” is usually too large a decision. Split the system into capabilities with clear inputs, outputs, users, service levels, data, and dependencies. A standard CRM may cover contact and pipeline records while a proprietary quoting workflow remains custom. That is two decisions with one integration boundary.
Core versus commodity is a useful prompt, but it cannot decide the outcome. A differentiated capability may still be bought if a product meets the acceptance cases and preserves strategic control. A common capability may still need a focused build when available products fail a hard constraint.
The UK Service Standard asks teams to understand total cost and preserve the ability to make different choices later. Treat that as a testable requirement: define what must remain replaceable, exportable, or independently operable before selecting an option.
Compare the same capability, against the same evidence, over the same decision horizon.
Comparable decision record
Ask the same questions of SaaS, custom build, and hybrid options.
| Decision dimension | SaaS / buy | Custom build | Hybrid / partner |
|---|---|---|---|
| Required outcome | Which acceptance cases work in the current product? | Which acceptance cases must be designed and built? | Which cases belong to the product and which remain custom? |
| Hard constraints | Which requirement, contract term, region, interface, or service level disqualifies it? | Which capability, deadline, budget, or ownership gap disqualifies it? | Which boundary or dependency makes the combination unsafe or unworkable? |
| Evidence status | Working trial, contract, export, API, support and security evidence | Prototype, estimate basis, architecture, staffing and delivery evidence | End-to-end test, interface contract, failure path and joint operating evidence |
| Operating owner | Customer owns configuration, access, adoption, vendor management and connected systems | Organisation owns product decisions, delivery, security, support, continuity and change | Ownership is split explicitly across product, custom layer, integration and incident path |
| Scenario cost | Licence, configuration, integration, migration, internal work, support, renewal and exit | Discovery, build, infrastructure, security, operation, support, change, continuity and opportunity cost | Product costs plus integration, custom operation, coordination and boundary failures |
| Security evidence | Supplier practice, product evidence, configuration, identity, data flow and contract | Secure-development practice, dependencies, deployment controls, monitoring and response | Evidence for both sides plus the interface, credentials, logging and responsibility boundary |
| Portability and exit | Export test, format, API, contract, switching help, deletion and replacement path | Code, data, accounts, licences, documentation, people, dependencies and rebuild path | Exit each component separately and test how the remaining system continues |
| Review trigger | Renewal, price or product change, acquisition, service failure, or new requirement | Material scope, demand, security, team, cost, or architecture change | Interface, vendor, ownership, volume, or operating-model change |
Three controls
- Same scope
- Every option answers the same required outcome, acceptance cases, and disqualifiers.
- Evidence
- Verified inputs, supplier statements, estimates, inference, and missing information remain visibly separate.
- Exit
- The decision includes how to replace, migrate, stop, or continue operating each component.
Next step
Get a second opinion on: Custom software vs SaaS
Send us what you are working on. We reply with a next step, not a sales pitch.
Build the comparison
Four moves that expose a weak recommendation.
Write acceptance cases and disqualifiers before meeting vendors
Use representative workflows, roles, data, volume conditions, exception paths, service levels, and required integrations. A weighted feature score should never compensate for a failed legal, security, portability, timing, or operating constraint.
Label the evidence behind every input
A working trial, signed contract, measured workload, supplier statement, estimate, reviewer inference, and missing answer carry different confidence. Keep the labels in the decision record so a polished demo cannot silently outweigh absent operating evidence.
Model scenarios and sensitivity over the agreed horizon
Choose a horizon that covers the relevant contract, investment, or product decision. Change adoption, volume, internal time, price, delivery, support, and exit assumptions. The recommendation is fragile if one optimistic input reverses it.
Test the operating and exit boundary
For a CRM plus proprietary quoting layer, test which system owns each record, how failures are retried, who supports the integration, how the quote history exports, and what continues if either component is replaced. Hybrid creates two operating surfaces and needs a deliberate architecture.
Common questions
What decision-makers ask about custom software and SaaS.
Is SaaS cheaper than custom software?
There is no transferable answer without a capability, requirement baseline, contract, adoption model, operating plan, and horizon. Compare the scenarios using the same cost categories and evidence status. A low licence price can coexist with expensive integration or change. A build estimate can omit operation, security, continuity, and displaced product work.
Does a custom build remove vendor lock-in?
No. A custom system can depend on a development supplier, key employees, cloud services, frameworks, proprietary components, licences, models, or undocumented operational knowledge. Confirm ownership and access to code, data, accounts, build and deployment paths, documentation, and dependency records. Then test whether another qualified team could operate or replace it.
How should security affect the choice?
Buying changes the evidence and responsibility split; it does not remove security work. NIST SP 800-218 provides secure-development practices that purchasers can also use when communicating with suppliers. CISA customer guidance covers contractual and software supply-chain evidence. For a build, verify the organisation can sustain those practices. For SaaS, verify supplier evidence plus customer configuration, identity, data flow, monitoring, and incident responsibilities.
Does the EU Data Act eliminate SaaS lock-in?
No. The European Commission explanation describes switching and portability requirements for covered data-processing services, including cloud and edge services. Scope, transition provisions, contracts, technical feasibility, excluded data, and the rest of the application architecture still matter. Test export and switching in practice and ask qualified counsel about applicability to the service and contract.
Should we evaluate SaaS before approving a custom build?
Run enough market and product evidence to show whether a credible buy or partner option exists. The depth depends on the decision. If no candidate passes a hard requirement, document that result and stop spending evaluation time. If one appears viable, test the same representative acceptance cases used for the build option.
How Some Tech Work handles the decision
The recommendation remains separate from implementation revenue.
Our build vs buy decision memo records the decision owner, constraints, options, evidence, scenario costs, operating responsibility, recommendation, conditions, dissent, and review trigger. Buy, hybrid, defer, and stop remain credible outcomes.
A deeper supplier review becomes vendor due diligence. Any later build or integration is separately scoped and approved, so the analysis does not depend on awarding Some Tech Work the implementation.
Written by
Vineet Talwar
Co-founder, Tech & Operations at Some Tech Work. WordCamp speaker across Europe and Asia, and host of the WP Shoutout podcast.
Start here
Ready to talk.Book a short diagnostic.
Tell us what needs fixing
We read every brief and reply within one business day.
Prefer to talk first?or request a tech stack audit →or email us directly →
Not sure where to start? Send the stuck decision, workflow, or page. We will say whether you need a diagnostic call, a tech stack audit, or a different first step.