Build vs Buy Software: Who Will Maintain It?
Build vs buy software starts with who will maintain it. Compare fit, support, adaptability and existing connections, then name who will own the ongoing work.
By Nick Bryant, Co-Founder and CTO, SMB Investor Network
6 min read
In brief
Build when the work needs a fit that available software cannot provide and you can support ongoing maintenance. Buy when an existing product fits the work and your team can own its setup, use and relationship with the provider.
A software choice can leave the business with ongoing work that nobody has agreed to maintain. Building could fit when available products cannot meet a necessary requirement and the business can support a custom application. Buying could fit when an existing product supports the work and the team can manage its setup and use. Start the build vs buy software decision by naming who will maintain it after the initial project ends.
By Tech-Enabled Operator Editorial.
A working demonstration does not answer that question. Someone still needs to handle changes, support users and resolve problems when the software no longer matches the work. A purchase moves some responsibilities to a provider. A build leaves your business responsible for arranging them. Neither choice removes the need for someone inside the business to understand the process.
The table below compares the two on who carries the work afterwards.
Compare build vs buy software by ongoing responsibility
| Criterion | Build software | Buy software |
|---|---|---|
| Fit to the work | You can shape the application around a requirement, but must explain and maintain that requirement. | You can use an established product if its available functions fit the work. |
| Ownership of maintenance | Your business must arrange technical maintenance and decide which changes matter. | The provider maintains the product; your business still owns configuration, use and connected processes. |
| Dependence on outside help | You may depend on whoever understands the code and its design. | You depend on the provider's support, product direction and any implementation help. |
| Adaptability | You can commission changes if the skills and knowledge remain available. | You can adapt within supported settings and features, subject to the provider's choices. |
| Connecting existing tools | A connection may address the gap without a separate application. | Existing connection features may address the gap without another product. |
Fit to the work: identify what must change
Judge technology by whether it can change the constraint on a business's growth, not by whether it replaces old tools. From the management side, start the same way: name the obstacle between the owner and the outcome, then choose the system. Applied here, describe the work problem before choosing software.
An operating constraint is the obstacle that limits the outcome you want. If work waits because nobody has authority to approve it, custom software may simply give that delay a new screen. A product with more features would leave the same delay in place.
Building could fit when a necessary way of working cannot be supported adequately by available products. Buying could fit when the work can use a product's supported process without losing something that matters to customers or staff. Do not treat every familiar habit as a requirement. Equally, do not discard a necessary exception because a demonstration makes the standard path look easy.
Ownership of maintenance: separate the process from the software
The process owner remains accountable for the work and its outcome. A technical maintainer keeps the software functioning. These responsibilities can sit with different people, but each needs a clear place to go when a problem crosses the boundary.
With a build, your business must arrange fixes and future changes. That responsibility remains even if an outside developer writes the application. Someone inside must explain what correct behavior means and decide whether a proposed change serves the work.
With a purchase, the provider handles maintenance of its product. Your team still needs to manage settings, access, records and the way people use it. A provider may correct a software fault without resolving an unclear handoff in your business.
Our guide to automation costs in small businesses considers obligations that can outlast the initial decision. Treat maintenance as continuing work with an accountable owner, regardless of how the software arrives.
Dependence on outside help: know what stays inside
Check whether the business has the knowledge to direct and support the choice it makes.
For a build, an outside developer may understand the application while employees understand the work. If neither can explain the other's assumptions, changes can become difficult to specify. Consider whether another maintainer could understand what the application does and why.
For a purchase, outside support may come from the provider or an implementation specialist. Ask which responsibilities each accepts. Product support, configuration help and advice about your business process are different services, even when they are discussed together.
The relevant question is whether the business can function when its usual helper is unavailable. Buying does not automatically remove dependence on a person. Holding the code doesn’t free the business from outside help either.
Adaptability: decide who can approve and make changes
Control over a custom application can be useful when the work needs to evolve. That control has practical limits: someone must understand the request, change the application and check its behavior. The ability to ask for a change is different from having the capability to maintain it.
Purchased software offers the features and settings its provider supports. That can suit work which benefits from an established approach. It may fit less well when an essential requirement falls outside that approach and the provider does not plan to support it.
Consider a hypothetical service business whose approval responsibilities change. A purchased product could fit if its settings accommodate the new responsibility. A custom application could fit if the requirement cannot be represented adequately elsewhere and a maintainer can support it. The choice turns on the actual requirement and continuing capability, not a general claim that custom means flexible.
Connecting existing tools: check whether the gap is a handoff
Before committing to a build or purchase, consider whether the tools already in use support the work but fail to pass information between them. In that situation, a connection could address the gap. It would still need an owner who understands what should pass between systems and who responds when that stops happening.
Integration can involve custom work or features already available in a purchased product. It is not automatically free of maintenance. Nor can a connection resolve disagreement about which records are correct or who acts on them.
The broader build, buy or integrate software guide places this alternative alongside the application decision. Keep it in consideration when the problem concerns a handoff rather than a missing capability.
When building could fit
Building could fit when the requirement matters to the work, available products cannot support it adequately, and your business can arrange continuing maintenance. The process owner should be able to explain what must work and why. Technical support should extend beyond the person who can produce the initial demonstration.
A wish to own software is not enough. If the requirement is still vague or future maintenance rests on an informal promise, the build depends on someone who hasn't agreed to carry it. Settle that before you commission it.
When buying could fit
Buying could fit when a product supports the required work and the team can operate within its supported approach. It also requires a clear internal owner for configuration, adoption and the relationship with the provider.
Check that the fit includes ordinary exceptions, not just the path shown in a demonstration. If keeping a purchased product useful would take extensive custom additions, you are partly building again, and someone has to maintain those additions.
Questions to ask
- What work is blocked, and would software address the cause?
- Which requirements are necessary, and which reflect habit?
- Who owns the process when the software behaves as designed but the outcome is wrong?
- Who maintains the application or configuration after the initial project?
- What happens when the usual developer, administrator or support contact is unavailable?
- Could connecting existing tools address the gap?
- Who decides whether a future change is needed, and who can carry it out?
Name the future maintainer
Before choosing a build or a purchase, name the future maintainer and the work they are agreeing to carry.
Source notes
Guest remarks are paraphrased; examples are our own.