When a process starts to stall, replacing the tool is an understandable first thought. Sometimes the answer is simple: an off-the-shelf product does the job. In other cases, adjusting the process or connecting existing systems removes the repetitive work. And sometimes the operating rules call for software of your own.
These options come with different costs and responsibilities. Choosing before you understand the work can leave a company paying for a poor fit, maintaining parallel controls, or funding a custom solution for a problem that already had a simpler answer.
The useful question is not “Which technology should we use?” Start somewhere else: which part of the work needs to improve, for whom, and within what constraints? The answer helps determine whether to buy, adapt, integrate, build, or combine approaches.
There are more than two options
Buy an off-the-shelf product
An existing solution is often a good candidate when it addresses a common need, such as business email, report generation, or basic contact management. You can start using features that already exist while the vendor handles the product’s general evolution.
Evaluate the fit against the real workflow, not just a feature list. Check permissions, reports, data export, support, price changes, and integration with tools the company already uses. A demo may show the happy path and skip the exception that takes up much of the day-to-day work.
Adapt the process or existing tools
“Adapt” can mean reorganizing a step in the work, configuring a product the company already pays for, or connecting systems that currently operate separately. If the tool supports the core process and the problem lies in data exchange or repetitive tasks, this route may address the cause with less maintenance than a new system.
There is also a difference between configuring a product and customizing its code. Deep customization can make upgrades more expensive, create dependence on a particular vendor, or complicate a future migration. Before taking that route, find out which changes the platform allows, who maintains them, and how they affect support and upgrades.
Build custom software
A custom solution may make sense when a workflow contains specific rules, those rules matter to the operation, or available products leave gaps that are difficult to work around. It lets a team design features around needs defined for that project.
That control comes with responsibility. Someone has to maintain the code, fix issues, handle infrastructure and security, update dependencies, document decisions, and plan new versions. The cost does not end when the first version goes live. Without a budget, owners, or a willingness to maintain the solution, custom development can create an obligation the company cannot sustain.
Combine ready-made and custom parts
The same choice does not have to apply to every part of the work. A company can use ready-made services for common activities and build only the workflow that connects those tools or applies a specific operating rule. This hybrid approach avoids rebuilding solved problems and focuses the investment where a real need exists.
The UK government’s Sourcing Playbook, written for public procurement, describes evidence-based evaluations that compare in-house delivery, market suppliers, and hybrid models. Its context differs from a private company, but it reinforces a useful idea: different components may call for different delivery approaches.
Define the problem before asking for a solution
Requests like “we need an app” or “the current system is outdated” describe an imagined answer. To find out whether it fits, turn the request into a description of the work that is going wrong or has become too costly.
Write down, in plain language:
- Who performs the process, and who depends on its outcome?
- What are the current steps, including approvals and exceptions?
- Which manual tasks, rework, or delays do you want to reduce?
- Which systems, data, and people need to be involved?
- Which timing, budget, security, or operational constraints must be respected?
- How will you recognize an improvement after the change?
You do not need to have every detail resolved up front. A first description can reveal which questions remain. It also helps avoid comparing proposals that look similar but assume different workflows, integrations, or responsibilities.
Compare the cost over time
The purchase price or development estimate answers only part of the financial question. To compare options fairly, include what it takes to start, operate, change, and, if necessary, leave the solution.
- Implementation
- Consider configuration, process design, data migration, integration, training, and the time required from the team.
- Recurring use
- Include licenses, subscriptions, hosting, external services, contracted support, monitoring, backups, and maintenance.
- Future changes
- Look at the cost of adding a step, changing a rule, supporting another user profile, or keeping up with more work.
- Exit and continuity
- Ask how to export data, recover history, replace an integration, and keep the operation running if the vendor, platform, or solution no longer fits.
A monthly license may reduce the initial investment, but it comes with recurring charges and limits set by the product. Custom software may require more investment up front and ongoing maintenance. Integrations can reduce manual work, but they also need attention when one of the platforms changes.
Microsoft’s build-or-buy guidance recommends considering cost, implementation time, control, technical expertise, support, and updates. The material is part of the Azure Well-Architected Framework, but these dimensions can help structure any comparison without making one option the default winner.
Six questions to guide the decision
- Does this process set the company apart? A common activity may be well served by an established product. A rule that defines how the company delivers a service, calculates a condition, or runs an operation may deserve more control. “Important” and “distinctive” do not automatically mean “must be custom-built”; first find out what an existing tool offers.
- How much of the workflow fits without risky workarounds? Compare real tasks with what the product does. Note where the team would have to change its routine, use parallel spreadsheets, repeat information, or rely on manual exceptions. Some adaptation may be reasonable; the cost appears when it accumulates or weakens a necessary rule.
- Which integrations and data are involved? Check whether the products exchange information as expected, whether data can be migrated, and who is responsible when a connection fails. An integration listed on a sales page may have plan, volume, or access limits that need confirmation.
- Who will operate and maintain it? Ready-made products need administration, training, and vendor follow-up. Custom software needs people responsible for its evolution and operation. In either case, clarify who handles incidents, applies updates, and communicates important changes.
- What dependencies will this create? Understand dependence on a vendor, technology, integration, or knowledge held by one person. Check whether documentation and data exports are available, whether you will have code access where relevant, and whether there is a viable continuity plan.
- What must be true for the decision to work? Write down the assumptions: the process can be adjusted, an API is available, a team can participate, or a contracted plan will remain in place. If an assumption is uncertain, turn it into a check before making a larger commitment.
Reduce uncertainty before investing more
If the answer is still unclear, there is no need to hide the doubt inside a long specification. Choose the most important assumption and look for evidence. You might test a product with representative tasks, confirm an integration with the vendor, map the current workflow with the people who perform it, or prototype the part of an interface that still raises questions.
A useful test represents real work. Include a frequent exception, a different access profile, and a handoff of data between systems. Ask the team whether it can finish the task without parallel controls. Record what the test did not answer so a short demo is not mistaken for proof that the whole operation is covered.
When the chosen route is custom development, use the same discipline to reduce risk: confirm rules with the people who know them, clarify the boundaries of the first scope, and agree on how deliveries will be evaluated. A smaller first version can help validate decisions before they spread through the system.
An example: orders moving across several teams
Imagine an operation where one team receives orders, another reviews them, and the orders then move to billing and delivery systems. Before building an entire platform, investigate how each step works, which data already exists, and where delays or corrections appear.
If a commercial product covers the process and lets you configure approvals, starting with it may be reasonable. If the problem is repeated data entry between systems, an integration may solve an important part of the workflow. If approval rules change according to conditions unique to the operation and existing options cannot represent them safely, it may be worth evaluating a custom module.
The analysis may lead to a combination: keep common tools where they work, connect what is disconnected, and build only the behavior that needs a specific solution. This is an illustration of the method, not a client case or a universal recommendation.
What a responsible proposal should make clear
Before comparing vendors, check whether each proposal explains what is included and under which conditions. A useful document describes the solution being considered, the stages, responsibilities, fees, assumptions, and relevant dependencies. It also explains how scope changes will be handled and how the client takes part in evaluating deliveries.
For custom development, also clarify who will have access to the code, documentation, environments, and required accounts. Confirm how handoff works and which warranty, correction, support, or evolution activities are included. These boundaries should match the agreement; an informal conversation does not replace a contract.
At RQDEV, discovery is intended to understand the problem, the people involved, the processes, integrations, and timing and budget constraints. The proposal organizes the solution, stages, fees, terms, and assumptions for evaluation. After the applicable formal agreement, technical planning details decisions and development proceeds incrementally. Validation, delivery, documentation, access, and support follow the workflow and boundaries agreed for each project.
That conversation may point to custom software, an integration, process changes, or a mixed approach. Discovery is meant to understand what makes sense before an initial idea becomes an execution commitment.
A good decision stays open to review
Needs change. A product that worked for a small team may leave gaps as the operation changes; custom software may become more expensive than the value it delivers; an integration may no longer be necessary after a process changes.
Record why the choice was made, which assumptions support it, and what signs would prompt a review. You do not need to predict every coming year. It is enough to avoid invisible dependencies and keep a route open for changing direction when the facts change.
If you are evaluating a solution, bring the current process, the tools in use, and the points that frustrate the team. You do not have to decide in advance whether to buy, adapt, or build. We can look at the context and discuss which next step is worth evaluating.