Buy business software when an established product can support the essential workflow with acceptable configuration, integration and operating responsibilities. Build when a meaningful requirement remains poorly served and the business can own the development and maintenance commitment. Between those choices, a configured product or a small custom layer may provide a better fit than either extreme.
Compare the same work, users and exceptions in every option. A subscription price is not the full cost of buying, and an initial development quote is not the full cost of building. The decision should explain how the system will operate, change and eventually be replaced, not only how quickly its first screen can be demonstrated.
Separate Essential Capability from Current Habit
Describe the outcome the workflow must produce. A team may currently use several spreadsheets to approve a customer request, but reproducing those sheets exactly is not necessarily the requirement. The requirement might be a traceable decision, appropriate access and a reliable handoff to the next team.
Interview the people doing the work and inspect representative cases. Identify where they repeat information, correct mistakes or make decisions outside the documented process. Those details help distinguish necessary flexibility from accumulated workarounds that should not be carried into a new system.
Identify What Truly Differentiates the Business
Some capabilities are common across many organisations, such as ordinary scheduling or basic contact records. Others may embody a distinctive pricing, approval or service-delivery process. Do not build commodity functions merely to claim ownership, but do not force an important differentiating workflow into an unsuitable product without examining the consequences.
Classify requirements as essential, useful or optional, and explain why. An essential requirement should have a concrete acceptance scenario. If everything is marked essential, the prioritisation is not doing its job and procurement may become a competition between oversized feature lists.
Compare Buy, Configure and Build as Real Options
For a purchased product, assess what works natively and what requires configuration, an add-on or a manual process. For a configured solution, identify the limits of supported customisation. For custom development, specify what must be built and which existing services can still be used safely.
Include the integration boundary in each option. A product can fit the visible task but lack the data access needed for the next operational step. Conversely, a custom application may not need to recreate an existing accounting or identity service if a clear supported connection meets the requirement.
The following matrix uses an illustrative approval workflow. It is a way to structure evaluation, not a claim about any named product or a measured comparison of vendors.
| Requirement | Buy or configure evidence | Custom-build evidence | Risk to record |
|---|---|---|---|
| Staff submit a request | Supported form and record model | Defined input and validation behaviour | Missing information or duplicate submissions |
| Manager approves within assigned scope | Demonstrated permission and approval rules | Tested role and relationship checks | Approval by the wrong person |
| Approved request reaches another system | Supported API or connector behaviour | Mapping, retries and acknowledgement | Lost or repeated downstream action |
| Staff investigate a failed handoff | Searchable status and recovery controls | Exception view and support runbook | Hidden manual work |
| Business exports its records | Representative export with relationships | Documented data model and export route | Supplier or implementation dependency |
Use the matrix to expose gaps rather than award arbitrary points. One unsupported essential permission rule may outweigh several attractive reporting features. Keep those decisions visible instead of burying them inside a total score.
Model the Work Required to Adapt Each Option
A product's gap may be resolved by changing a nonessential habit, configuring a supported feature or building an extension. Record which approach is proposed and who will maintain it. An unofficial workaround that breaks after updates is a different commitment from a supported configuration.
For custom software, challenge unnecessary scope. Do you need a bespoke reporting engine, or would a controlled export satisfy the current decision? Does the first release need every workflow variation, or a complete bounded process with an explicit exception route? Reducing scope should preserve a functioning outcome, not leave disconnected screens.
Review Data Quality Before Blaming the Software
Inconsistent identifiers, unclear ownership and missing fields can undermine either option. Include data preparation, migration and reconciliation in the estimate. A new interface does not automatically make conflicting records accurate.
Test a representative import and subsequent update. Confirm how the system matches existing records and what happens when a source value changes. Ask whether the business can inspect and correct errors without losing the original context or creating another duplicate.
Compare Ownership Costs Over the Same Period
For purchased software, include licenses, configuration, integrations, training, support and any relevant usage-based charges. Confirm current commercial terms for the actual account and required features. Do not assume the entry-level plan includes every capability shown in a demonstration.
For custom software, include discovery, development, testing, hosting, monitoring, security maintenance and future changes. Account for documentation and the time needed for another team to take over. Owning source code without the knowledge or access required to operate it is incomplete practical ownership.
Make Change Responsibilities Explicit
Ask how a new field, changed approval rule or additional user group would be handled. Who can make the change, how is it tested and what recurring cost does it introduce? Compare this against likely business changes rather than an unlimited hypothetical future.
Distinguish a forecast from a commitment. Estimated internal time savings should have a stated baseline and assumptions. A proposal should not promise a financial return without evidence about actual work, adoption and exception handling. Replace assumptions with measured pilot results when they become available.
Verify Data Access and Exit Before Committing
Review the contractual and technical ability to access your information, with appropriate legal input where needed. Request a representative export and inspect whether it includes the fields, relationships and files the business would need elsewhere. A CSV button does not necessarily provide a complete migration path.
For custom work, confirm repository ownership, deployment accounts, documentation, dependency licenses and recovery access. For purchased software, confirm available interfaces, export limits and the process if the subscription ends. Avoid assuming that one route has no dependency simply because it is described as owned or open.
Consider the People Who Can Support the System
A specialist custom implementation may be difficult to hand over if its design is undocumented. A highly customised purchased platform can create a similar dependency on the original consultant. Ask another qualified person to follow the setup or recovery documentation in a controlled environment before considering handover complete.
Document the support boundary when several suppliers are involved. If an integration fails, the business should not have to discover which vendor is responsible during the incident. Name the initial contact and the evidence each team needs for escalation.
Test the Hardest Requirement Before Procurement
Choose the requirement most likely to invalidate the option and demonstrate it with representative users and synthetic data. Include an exception, denied action and recovery case. A polished happy-path demo is insufficient when the business depends on permissions or unusual approval rules.
For security-related behaviour, ask for evidence rather than broad assurances. OWASP's authorisation guidance distinguishes identity from permission. A successful login does not prove that a user is restricted to the correct records and actions.
For a portal use case, the client portal requirements guide provides a more detailed role and workflow exercise. Use it to test whether the product or proposed application matches the actual client relationship model.
Agree What the Proof of Concept Must Produce
Specify the starting data, actions, expected outcome and evidence to retain. Record setup effort and manual interventions as well as whether the result eventually worked. If the demonstration required a developer to repair data behind the scenes, that is relevant to the operating model.
Do not let a proof of concept quietly become production without the necessary review. Temporary access, incomplete logging or manual deployment may be acceptable in a controlled experiment but not in a live business system. Keep the acceptance boundary clear.
Make a Conditional Recommendation and Record It
Summarise the chosen option, the requirements it satisfies and the assumptions that remain. State why the alternatives were not selected. Include ownership, expected operating work and the evidence that supports the recommendation.
If a critical feature exists only on a vendor roadmap, do not treat it as delivered. Establish whether the business can proceed without it, whether a supported alternative exists or whether the decision should wait. Future promises need an explicit place in the risk record.
Set review triggers, such as a changed workflow, material pricing change, unsupported dependency or repeated operational failure. The purpose is not to reopen procurement constantly, but to recognise when the basis of the original decision no longer holds.
Use the Decision Record to Scope the Next Step
If buying is the right fit, proceed with a clear configuration, migration and acceptance scope. If building is justified, turn the proven requirements into a focused delivery brief. A hybrid choice needs especially clear boundaries so two systems do not compete to own the same data or action.
When defining a web application project, share the fit matrix, prototype evidence and operating responsibilities. They help the team build only what the business needs and give stakeholders a defensible reason for the investment beyond preference for a particular tool.
Frequently Asked Questions
Is custom software always more expensive?
No universal comparison is reliable without the same scope and operating period. Purchased software can carry configuration, integration and recurring costs; custom software carries development and maintenance responsibilities. Compare the complete workflow and lifecycle rather than one subscription price against one build quote.
Can we combine SaaS with a custom application?
Yes, when the boundary is clear and supported. Assign data ownership, define the integration and test failure recovery. A hybrid approach can avoid rebuilding common capabilities, but it also creates a connection that needs monitoring, documentation and an accountable maintenance owner.
Should we copy our spreadsheet exactly into software?
Not automatically. Understand the outcome, decisions and exceptions first. Some spreadsheet structure may represent useful business knowledge, while other parts reflect old workarounds. Preserve the necessary rules and improve the process before encoding every current habit into a more expensive system.
What if a vendor promises a missing feature later?
Treat it as unresolved unless there is a dependable commitment that satisfies your procurement requirements. Decide whether the current product is acceptable without it. Do not base an essential workflow on an unverified future capability or present roadmap language as evidence that the feature exists today.
Who owns data in a purchased system?
Verify the applicable agreement and actual access or export behaviour. Ownership language alone may not explain how records, files and relationships can be retrieved. Obtain appropriate contractual advice where necessary and test a representative export before relying on an assumed exit path.
What evidence should a proof of concept produce?
It should demonstrate the hardest relevant workflow, permissions, exceptions and recovery using representative users and safe data. Retain results, setup effort and unresolved limitations. A convincing screen is useful, but the decision needs evidence that the operational requirement can be met reliably.
