Three routes, not two
The familiar question is “build or buy?”, but there is usually a third route that gets overlooked: configure what you already own. Many organizations hold licences for platforms with capabilities that nobody has switched on. Before looking outward, it is worth checking what your current tools can do with settings, rules and templates rather than new code or new contracts.
Each route involves a different mix of cost, speed, control and ongoing responsibility. None is best in general. The useful question is which fits this need, at this point, for this organization.
Configure what you already own
Configuring means adapting an existing system using its built-in options: fields, workflows, permissions, reports, templates. Typically no programming is needed.
Strengths. It is usually the fastest and cheapest route, because the contract, security review and user familiarity already exist. It avoids adding another system to support and integrate.
Limits. The existing product may fit the need only awkwardly, and stretching it can produce a fragile workaround. Heavy configuration can also create its own dependency, because complex rules inside a tool are hard to move later, a risk discussed under vendor lock-in. Spreadsheets are a common example of configuration-by-habit; their strengths and limits are covered under spreadsheet systems.
A good fit when the need is modest, close to what the tool is designed for, and not likely to grow far beyond it.
Buy packaged software
Buying means adopting a product built for a general market and adapting your processes to it, with some configuration.
Strengths. The product has been used by many organizations, so common needs are typically covered. The vendor takes on development, updates and much of the security maintenance. Time to start can be short compared with building.
Limits. You accept the vendor’s design and roadmap. Features you need may be missing, and features you do not need may add complexity. Recurring fees continue indefinitely, and the product may change in ways you did not ask for. Careful vendor due diligence and an honest look at total cost of ownership matter more here than the list price.
A good fit when the need is common across many businesses, such as accounting, document storage or help desk, and being distinctive in that area gives you no advantage.
Build custom software
Building means designing and developing a solution for your specific process, either in-house or through a contracted developer.
Strengths. It can match your process closely and give you control over features and data. It makes sense where the process itself is a source of advantage and no product comes close.
Limits. The initial build is only part of the story. Custom software needs maintenance, security fixes, documentation, hosting and people who understand it, for as long as you use it. Estimates for software projects are often optimistic, and requirements tend to shift during development. Dependence on a small number of developers, or one, is a real continuity risk, a form of the single points of failure problem. If the people who built it leave, the knowledge may leave with them.
A good fit when the need is genuinely unusual, the process matters strategically, and you have the resources to own the software for years.
Questions that help you decide
Work through these before choosing a route:
- How common is the need? The more standard it is, the stronger the case for buying or configuring.
- How much does it matter strategically? Differentiating processes may justify custom work; routine ones rarely do.
- Can we sustain it? Think about who will maintain, secure and support the solution in three years, not just who will deliver it.
- How quickly do we need it? Configuring and buying are typically faster, though neither is instant.
- What will it connect to? Integration effort can outweigh the build or purchase cost, and is explored under system interoperability.
- What happens if we want to leave? Custom code is not immune to lock-in; it just locks you in to your own past decisions.
- What does the whole life cost? Compare all three routes over several years, including support and staff time.
Hybrid answers are common
Real decisions often blend the routes. A packaged core with a small custom extension, or an existing platform configured heavily and supplemented by a bought add-on, can fit better than any pure option. The risk is that blends multiply the number of things to maintain. Keep customization at the edges and avoid modifying the core of a bought product where possible, since changes to the core can complicate upgrades.
Revisiting the decision
The right answer today may not stay right. A configured spreadsheet that served a ten-person team may strain at a hundred people, and a custom tool that was once distinctive may become a commodity that a packaged product now handles well. Build in a point at which you review the choice, perhaps at contract renewal or after a significant change in scale. Honest reviews cost little compared with continuing down a route that no longer fits.
No framework can remove the uncertainty. A written comparison of the three routes against your requirements, reviewed by the people who will live with the result, is usually the best protection against choosing out of habit or enthusiasm.