Choose SaaS when your process is common, the product fits without damaging workarounds and speed matters more than uniqueness. Choose bespoke software when a distinctive or complex process creates meaningful value, existing products cannot support it economically and you can fund long-term ownership. Many UK businesses should use a hybrid: proven SaaS for commodity functions, integrations between systems and custom software only around the part that differentiates them.
The decision is not “cheap subscription versus expensive build”. Compare whole-life cost, process fit, delivery risk, data control, change speed and exit options over a realistic period.
Is the process genuinely distinctive?
Payroll, email, video calls and standard bookkeeping are rarely sensible bespoke builds. Mature products spread compliance, security and product development costs across many customers. Your team benefits from established workflows and updates.
Custom software becomes plausible when the process itself is a source of advantage or when fragmented tools create material delay, rekeying and errors. Examples include specialist quoting, field operations, customer self-service tied to unusual rules or an internal workflow across several legacy systems.
Document the process before choosing technology. Remove unnecessary approvals and duplicated steps first. Otherwise you may spend money preserving a poor workflow in code.
How do you test SaaS fit?
Run a time-boxed trial with representative users and realistic scenarios. Demonstrations tend to follow the product’s best path; trials expose permissions, reporting, imports and exceptions.
Build a requirements matrix with four levels: essential, high value, optional and excluded. Test essential requirements directly. Record where the product needs configuration, another subscription, an integration or a manual workaround. A minor workaround used twice a year differs from one affecting every order.
Check:
- Role and permission granularity
- Import, export and deletion methods
- API coverage and usage limits
- Audit history and reporting
- UK-relevant tax, currency or address needs
- Accessibility and mobile use
- Support hours and incident communication
- Product roadmap dependence
- Contract renewal and price-change terms
Avoid selecting primarily by feature count. Unused features can increase complexity and training.
When does bespoke software make commercial sense?
Build a simple value case. Estimate current handling effort, delay, avoidable rework, lost opportunities and supplier costs. Then describe the change a first release can create. Use ranges where evidence is uncertain and avoid treating every saved minute as cash automatically returned to the business.
A bespoke project should have an executive owner, operational product owner and regular access to end users. It also needs a budget beyond first launch. Software requires monitoring, support, security maintenance, dependency updates and iterative improvement.
Start with the smallest end-to-end release that creates value. A narrow working workflow gives better evidence than a year-long attempt to replace every system simultaneously.
How should costs be compared?
For SaaS, model licence tiers, user growth, implementation, configuration, migration, integrations, training, support and likely add-ons. Include the operational cost of workarounds and future export.
For bespoke software, early planning might range from tens of thousands of pounds for a focused application to substantially more for a multi-role platform with complex integrations and assurance requirements. This is only a planning frame and requires a scoped quote. Delivery cost depends on discovery, workflows, roles, interfaces, migration, integrations, security, testing and support.
Compare three- to five-year scenarios and make assumptions visible. Do not assume the custom system has no ongoing cost after launch or that SaaS subscription prices remain unchanged. Use sensitivity cases for user growth, change demand and integration complexity.
Who controls the data and intellectual property?
With either route, identify the controller and processors for personal data, where data is held, applicable retention and how data subjects’ rights are supported. The ICO accountability framework helps organisations structure governance.
For SaaS, inspect export formats, API access and deletion after termination. An export that cannot recreate relationships or attachments may not be a practical exit route.
For bespoke work, the contract should address ownership or licensing of source code, pre-existing components, documentation, designs, infrastructure and deployment scripts. Your desired commercial position must be explicit; paying for development does not by itself answer every intellectual-property question. Obtain legal advice for the agreement.
Which security questions matter?
Security depends on implementation and operation, not whether a product is custom or subscribed. A SaaS provider may have a mature security team, while a poorly configured account can still expose data. A custom system gives design control but leaves you responsible for funding controls and maintenance.
Review authentication, multi-factor support, least privilege, encryption, logging, backup recovery, vulnerability management, incident reporting and supplier access. The NCSC Software Security Code of Practice sets out principles for secure software products. For cloud services, use the NCSC cloud security principles to structure due diligence.
Risk should determine the depth of assurance. A public brochure tool and a system holding sensitive client records should not receive identical procurement checks.
Could integration be the better answer?
Often. Connecting existing systems can remove duplicate entry while retaining mature capabilities. Integration still requires ownership: APIs change, credentials expire, records conflict and failures need monitoring.
Consider a lightweight custom layer that coordinates SaaS products, provides a single task view or enforces business rules. This can reduce initial scope, but test the total subscriptions and dependencies. A chain of five products is not automatically simpler than one tailored system.
Decision checklist
- The target process is documented and simplified
- Essential requirements have been tested, not assumed
- Workaround frequency and impact are understood
- Three- to five-year cost assumptions are visible
- Data flow, retention and exit are documented
- Security assurance matches business risk
- Integration limits and failure ownership are known
- Bespoke ownership and licensing terms are explicit
- A named product owner has time to participate
- The first release has measurable acceptance criteria
Frequently asked questions
Is bespoke software always more flexible?
It can be changed to fit your priorities, but every change requires design, delivery and maintenance. Flexibility depends on architecture, documentation and continued capability.
Is SaaS always faster to launch?
Usually for standard needs, but migration, configuration, procurement and integration can still take time. Validate with a trial and implementation plan.
Can we switch from SaaS to bespoke later?
Yes, if data can be exported and the transition is planned. Preserve clean data, documented processes and integration knowledge from the start.
Should we build an MVP?
Build a minimum viable product only when it tests a commercial or operational assumption. It still needs adequate security, privacy and reliability for its users.
