Build vs buy software A build vs buy software choice should compare workflow fit, risk, cost and long-term control.
Build or buy is usually a trade between two imperfect options. A subscription product brings its own workflow, roadmap and constraints. Custom software brings discovery, delivery and maintenance responsibilities. The useful question is which set of compromises the organisation can operate responsibly.
Describe the work before comparing products
Choose one real process and map it from start to finish. Record the people involved, information they receive, decisions they make, exceptions they handle and systems they update. Include the awkward cases; they are often where a standard product stops fitting.
Separate requirements into three groups:
- Essential: without this, the process cannot operate safely or legally.
- Valuable: this saves meaningful time, reduces errors or improves the customer experience.
- Preference: useful or familiar, but the team could adopt another method.
If every request is essential, the organisation has not made the trade-offs needed for either route.
When buying is usually the stronger option
Buy or configure an established product when the workflow is common, the market already serves it well and the business can adopt the product’s process without losing an important advantage. Payroll, basic accounting and standard support ticketing often belong in this category because mature products also carry a large burden of updates and compliance work.
A product is still an implementation project. Data must be cleaned, permissions decided, integrations configured, staff trained and old processes retired. Include this work when comparing cost and timing.
When building deserves investigation
Custom development may be justified when the workflow is central to how the business delivers value, standard products create repeated workarounds, or several systems must be coordinated in a way that products cannot support reliably.
“Our process is unique” is not enough. Quantify the consequence of the mismatch: hours of duplicate entry, missed handoffs, preventable errors, licence cost for unused modules, or customers unable to complete an important task. That evidence helps define the smallest custom capability worth building.
Score both options against the same questions
Use a score from one to five and attach a short explanation to each answer:
- Workflow fit: how much essential work is supported without manual workarounds?
- Implementation: what data, configuration, training and process change are required?
- Integration: are documented APIs available, and who supports them when they change?
- Permissions and audit: can access, approvals and activity history match the risk?
- Data portability: can the organisation export complete, usable records?
- Reliability: what availability, backup, recovery and support arrangements exist?
- Roadmap control: who decides when a feature changes or disappears?
- Internal capability: who will own configuration, support and improvement?
Weight the questions before scoring. A polished interface should not outweigh data export or audit history when those are operational requirements.
Compare total cost over a useful period
For a product, include licences, usage charges, implementation, migration, integrations, premium support, training and the staff time spent on workarounds. Model how the bill changes when users, transactions or storage increase.
For custom software, include discovery, design, development, testing, hosting, monitoring, security updates, support, documentation and future platform changes. Also include the time of staff who must explain the process and test releases.
Use more than one scenario. A base case, growth case and exit case reveal whether an option becomes difficult when usage rises or when the organisation needs to leave.
Consider a configured middle path
Many decisions are not purely buy or build. A standard CRM can remain the system of record while a small custom portal handles a specialised customer journey. An automation layer can remove duplicate entry without replacing the accounting platform. This approach works only when ownership and failure handling are clear.
Do not create custom code merely to avoid changing a poor process. Remove unnecessary approvals, fields and reports first. Software should support a clearer operation, not preserve every historical workaround.
Run a proof before committing
Use representative data and one end-to-end workflow. For a purchased product, configure the difficult permissions and integration—not only the vendor’s ideal demonstration. For a custom option, prototype the highest-risk assumption before building the complete interface.
Define the decision date, owner and evidence required. Record why the rejected option was rejected so the organisation can revisit the choice when costs, scale or products change.
Scoring one decision
A 40-vehicle plant hire company is choosing between an off-the-shelf rental system at £480 a month and a custom build quoted at £46,000 with £900 a month of support.
Over three years that is £17,280 against £78,400, so the packaged product wins on cost by a wide margin. The question is whether it covers the part that actually distinguishes the business: they hire by the half-day, price by site postcode band. their drivers confirm delivery on a phone with no signal.
The trial reveals the packaged system handles the first two through configuration and cannot do the third at all. So the useful answer is neither option as quoted. They buy the packaged system and build only the offline delivery app against its API, for about £11,000. The framework’s job was to find that split, not to pick a side.
Sources and further reading
- GOV.UK Service Standard: choose the right tools and technology — includes the need to justify what technology to build and what to buy.
- UK Government Technology Code of Practice — lifecycle criteria for designing, building and buying technology.
If the answer is still unclear, our custom software and CRM service can begin with a bounded discovery exercise rather than a commitment to a full build.
Quick build vs buy software action plan
- Write down the core workflow. Write down the result. Name one owner.
- Mark needs that cannot change. Test this step. Keep proof of the test.
- Test a standard tool first. Use real data. Check each fact.
- Count setup and licence costs. Ask one user. Note what feels hard.
- Count build and support costs. Fix each fault. Run the check again.
- Check data export and exit terms. Set a due date. Review the result.
- Score risk for each option. Write down the result. Name one owner.
- Set a date to review the choice. Test this step. Keep proof of the test.
- Choose one clear goal. Use real data. Check each fact.
- Name the owner for each task. Ask one user. Note what feels hard.
- Test the full path before launch. Fix each fault. Run the check again.
- Set the next review date. Set a due date. Review the result.
- Keep the plan where staff can find it. Write down the result. Name one owner.
- Use plain words in each note. Test this step. Keep proof of the test.
- Save proof for each key check. Use real data. Check each fact.
- Fix one issue at a time. Ask one user. Note what feels hard.
- Check the result with a real user. Fix each fault. Run the check again.
- Remove work that does not help the goal. Set a due date. Review the result.
- Share each major change with the team. Write down the result. Name one owner.
- Run the same checks after each update. Test this step. Keep proof of the test.
- Check the source of every key fact. Use real data. Check each fact.
- Keep private data out of public notes. Ask one user. Note what feels hard.
- Plan what to do when a check fails. Fix each fault. Run the check again.
- Give each choice a clear reason. Set a due date. Review the result.
- Keep old files until new work is proven. Write down the result. Name one owner.
- Ask for help when the risk is high. Test this step. Keep proof of the test.
- Check phone and desktop views. Use real data. Check each fact.
- Make the next step easy to find. Ask one user. Note what feels hard.
- Track the result that matters most. Fix each fault. Run the check again.
- Close each task when proof is saved. Set a due date. Review the result.
Use this build vs buy software plan as a live check. Keep the notes short. Review the work after each major change.
