Contents
The build-versus-buy decision starts with the work your organisation needs to do. Compare a packaged product, a configured product, an integration and a bespoke build against the same essential journeys. A hybrid approach may fit better than treating the choice as a single all-or-nothing decision.
Identify the journeys that must work
Choose a small set of representative tasks and describe their inputs, decisions and outputs. Include exceptions: an order that needs approval, a record with missing information, or a user whose access has changed. Ask prospective suppliers to demonstrate those journeys with synthetic examples.
Distinguish a requirement from a preference inherited from today's process. A familiar screen layout may be negotiable; a required approval or a data export needed by another team may not be. Name the person who can decide when the organisation should change its process instead of customising software.
Test the packaged option beyond the demonstration
For a product you could buy, establish what works as standard, what needs configuration and what depends on custom development or another supplier. Check that the edition and licence being proposed include the capabilities you evaluated. Ask how those settings and extensions behave when the product is upgraded.
Review integration and data exit in practical terms. Can you export the records and attachments you need in a usable structure? Can your other systems access the required operations? Ask for documented limits and a representative trial rather than assuming that the words API or export cover your intended use.
Make the case for bespoke work explicit
A bespoke build deserves consideration when essential workflows cannot be supported acceptably by available products, or when control over the product's behaviour is central to the business. Describe the specific gap and the value of closing it. Avoid commissioning a build solely because every existing product has some imperfections.
The build option includes responsibility for design decisions, testing, releases and continuing maintenance. Establish who will own priorities and who will operate the software after launch. Source access is useful, but a maintainable handover also needs usable documentation, deployment knowledge and an organisation prepared to make decisions.
Compare whole-life responsibilities
Use the same evaluation period and assumptions for each option. Consider licence or development costs, implementation, migration, integration, training, operation and a possible exit. Keep uncertain costs visible rather than presenting a precise total supported by weak assumptions.
Assess fit and responsibility separately. A packaged product may meet the core workflow but introduce a dependency on a vendor's roadmap. A bespoke product may give greater control over changes while requiring an ongoing engineering capability. Decide which responsibilities your organisation can realistically sustain.
Include an integration option where an existing system already does part of the job well. A focused connector or a small application around established systems may avoid replacing a working capability. Validate the boundaries, error handling and data ownership before treating that option as simple.
Choose the next evidence-gathering step
If the packaged option has one critical uncertainty, run a trial against that workflow. If the bespoke option depends on an unfamiliar system, investigate the integration before committing to the whole build. Give the exercise a question to answer and an agreed basis for accepting or rejecting the option.
Record the decision, the assumptions supporting it and the circumstances that would make you revisit it. That creates a useful handover for procurement and delivery: the team can see why an option was chosen and which trade-offs it is expected to preserve.
Worked build-versus-buy comparison over three years
Imagine a fictional operations team choosing between a configurable product and a bespoke request portal. Assume the bought option costs £8,000 to configure, £900 a month for licences and £3,000 a year for specialist administration. Its three-year cash allowance is £8,000 + £32,400 + £9,000 = £49,400. Assume the build costs £38,000 initially, £250 a month to host and £8,000 a year to maintain: £38,000 + £9,000 + £24,000 = £71,000. Both exclude VAT, migration, internal staff time and future feature expansion. These invented figures are an exercise, not supplier prices or market averages.
Now test fit. The bought product handles ordinary requests but cannot enforce one required approval boundary. If that is a hard requirement, its cheaper total does not establish an acceptable purchase. Ask whether configuration, a small extension or a process change can meet it, and price the resulting option. Conversely, if the boundary is optional and staff can adopt the standard workflow, the £21,600 difference deserves serious consideration.
Record five columns for each option: essential workflow fit, data export, integration evidence, three-year operating responsibility and exit cost. Mark each essential requirement demonstrated, proposed or unresolved. Do not average a failed essential control against attractive features. Use a bounded trial to settle the decisive unknown before committing to a custom build.
How this relates to Veda Software’s work
Powerleague illustrates a portal shaped around venue ordering and fulfilment. That demonstrates a reason to investigate workflow fit, not proof that bespoke development is always preferable.