Internal tool or off-the-shelf software: how do you decide?

Define the workflow before the solution

The build-or-buy decision becomes clearer when the workflow is described in detail. Write down who performs each step, what information is needed, what decisions are made, which systems are involved and what a successful result looks like. “We need a CRM” is not a workflow. “A coordinator assigns incoming requests, checks availability, sends a quote and records the outcome” is specific enough to compare.

Separate essential rules from personal preferences. A legal requirement, approval step or calculation may be essential; a favourite screen layout may not be. Mark the steps that differentiate the business and the steps that are common across many companies. Standard software is often strong at common tasks, while custom development becomes more attractive around a genuinely unusual process.

Also define the cost of doing nothing. Manual work, duplicate entry, missed follow-ups, slow reporting and inconsistent decisions are real costs. Without this baseline, a custom project can seem justified simply because its features sound appealing, while a standard product may already remove most of the expensive friction.

Understand where standard software fits

Off-the-shelf software can offer a faster start, established support, security updates, documentation and a community of users. It may include permissions, analytics, integrations, billing and accessibility work that would take time to recreate. A subscription also turns some technical responsibility into an operating expense that is easier to forecast.

The important question is not whether a product has many features. It is whether the core workflow can be completed reliably by the people who need it. Test the real process with realistic data. Look at setup, search, exports, approvals, exceptions and reporting, not only the demonstration path. Identify where users must change their behaviour and whether that change is acceptable.

Check the boundaries of the product. Can you access your data? Are integrations documented? What happens if a key feature changes? Can the vendor meet your privacy, security, accessibility and support expectations? A standard product is not automatically low risk. Its long-term value depends on fit, provider reliability and the cost of working around its limits.

Recognise when an internal tool is justified

An internal tool is more compelling when the workflow is central to the business, difficult to represent in standard software or a source of meaningful competitive advantage. It can combine specific rules, data and permissions in a way that reflects how the team actually works. It may also provide a better experience for a small group whose needs are not well served by a broad product.

Do not treat uniqueness alone as enough. A process can be unusual because it is inefficient or undocumented. Before building, simplify the workflow and confirm that the rule is worth preserving. If only a few people use the tool, check whether a manual process or configuration of existing software would be sufficient.

Ownership is the hidden commitment. Someone must define requirements, maintain integrations, fix defects, handle access, monitor performance, update dependencies and support users. If the original builder leaves, the business still needs knowledge and documentation. An internal tool is a product the company owns, not a one-time project that ends at launch.

Compare integrations and data ownership

Map the systems that need to exchange information. Include customers, accounts, payments, documents, calendars, reporting and any operational database. For each connection, define the source of truth, update timing, error handling and owner. A tool that looks inexpensive can become costly when information must be copied manually between systems.

Standard software may have ready-made integrations, but verify their limits. A connector might sync only selected fields, run on a delay or require a higher subscription plan. Custom software can offer precise data flows, but each connection becomes your responsibility to secure, monitor and update.

Data portability matters in both directions. Understand how to export records, close an account, change providers and preserve an audit trail. Decide who can access data and how permissions change when staff join or leave. Clear ownership prevents a tool from becoming an inaccessible container of critical business knowledge.

Calculate the total cost of ownership

Compare more than a licence price or development quote. Include discovery, configuration, migration, training, integrations, design, testing, support, security, accessibility, analytics, hosting and ongoing maintenance. For a subscription, include user growth, plan changes, implementation and exit costs. For custom software, include product management and the cost of keeping technical knowledge available.

Time is part of the cost. A standard product may require staff to adapt or clean data. A custom tool may require the business to make decisions, review releases and provide support. Estimate the effect on operations during the transition. A technically cheaper option can be more expensive if adoption is slow or work is disrupted.

Consider reversibility. It is usually easier to stop configuring a standard product than to recover the cost of a large custom build. A small internal prototype, limited subscription pilot or manual workflow can reduce uncertainty before a major commitment. Test the riskiest assumption first: process fit, data access, adoption, integration or ownership.

Make a decision you can maintain

Choose standard software when the workflow is common, speed matters, the compromises are acceptable and a reliable provider can meet your requirements. Choose an internal tool when the workflow is distinctive, strategically important and worth owning, and when the business can fund maintenance beyond the first release. A hybrid approach can work when a standard system handles common records while a focused tool supports the unique step.

Document the decision and its review point. Record why the route was chosen, what was deliberately excluded, which assumptions were tested and what would trigger a change. Define success through completed work, fewer errors, faster response, adoption, support load and cost—not through the number of features delivered.

The strongest choice is not the one with the most control or the lowest initial price. It is the one the business can use, understand and maintain as the workflow changes.

Sources

• Software maintenance · NIST
• SaaS overview · Google Cloud
• User research · Nielsen Norman Group

Frequently asked

When should a small business buy software?

Buy when a standard product covers the important workflow, can integrate with necessary systems and offers acceptable support, security and accessibility. Configuration is often cheaper than creating common functionality.

When is an internal tool worth building?

When a distinctive workflow is strategically important, standard products create costly compromises and the business can provide long-term ownership and maintenance.

Is a hybrid approach possible?

Yes. A SaaS product can manage common records while a focused internal tool handles a unique process. Define data ownership and integration boundaries carefully.

What is the most common build-or-buy mistake?

Comparing a development quote with a subscription price while ignoring migration, training, support, integrations, maintenance and the cost of changing the workflow.