Describe the work before choosing the product
Map the process, users, information and exceptions. Separate essential requirements from preferences inherited from the current system. Ask which steps create value and which exist only because staff work around an old limitation. This can reveal that a standard product already fits, that a modest integration would help, or that a genuinely distinctive workflow needs development.
Agree what success would look like in daily operation, not just which features should appear on a sales demonstration.
Compare both options on the same basis
| Question | Standard product | Bespoke system |
|---|---|---|
| Process fit | Adapt to supported workflows | Build around agreed requirements |
| Changes | Depend on configuration and vendor roadmap | Depend on development and testing capacity |
| Maintenance | Shared product updates, plus your configuration | Explicit responsibility for your application |
| Exit | Check exports and contractual limits | Check source, accounts, documentation and handover |
These are tendencies, not promises. A configurable product can be complex, and a poorly documented bespoke system can create serious dependence.
Calculate the cost of operating it
Include setup, data preparation, licences, integrations, user training, support, hosting, testing, future changes and eventual exit. Staff time and duplicate administration matter too, but estimated time savings should not automatically be described as cash savings. Ask who will carry each ongoing responsibility and whether the organisation has that capacity.
Compare equivalent service levels. A basic subscription and a fully supported custom system are not meaningful cost alternatives unless both meet the actual requirement.
Test the difficult cases early
Do not assess only the tidy demonstration path. Try a cancellation after payment, a customer with multiple accounts, a failed import or an approval that changes halfway through. Ask the vendor how these cases work today and what requires additional work. For bespoke delivery, make the same cases part of the specification and acceptance checks.
A short proof of the hardest integration or exception can reduce uncertainty more than a longer presentation of ordinary features.
Consider a hybrid approach
It is often sensible to keep a standard system for common work and add a focused application or integration around the distinctive process. For example, an illustrative workflow might retain an accounting product while a custom portal handles specialist customer approvals. Define which system owns each record and how corrections move between them. Without that boundary, the hybrid can create competing databases and more manual reconciliation.
Make ownership and change explicit
Document source-code rights, hosting accounts, data access, third-party dependencies, release arrangements and handover requirements. Ownership of code alone does not ensure that another team can run it. Similarly, a product’s export function may not include all the history or attachments needed for migration. We recommend selecting the option through a written decision record: what it solves, what it does not solve, expected ongoing work and the reason the trade-off is acceptable.
Common questions
Is bespoke software always more expensive?
No reliable answer exists without equivalent scope and operating assumptions. Compare lifetime costs and fit rather than the initial invoice alone.
Can a standard product be customised?
Often, but distinguish supported configuration from changes that complicate upgrades or depend on a specialist supplier. Confirm the maintenance implications.