When should a business build custom software?

Start with the job, not the feature list.

Choose one workflow or customer journey that needs to improve. Describe its trigger, the people involved, the information used and what completion means. Include exceptions. A request for a dashboard or an application says little about whether software will solve the problem.

For example, an operations team might need to coordinate a request across several departments. The important requirement is not a new screen. It is knowing who owns the next action, keeping one authoritative record and handling exceptions without losing the request. Those needs give you something concrete to compare against existing products.

Compare three routes against the same requirement.

Buying a product gives you an established capability and an external maintenance owner. Configuration can adapt that capability without making you responsible for an entire application. A focused integration may fill the gap between two otherwise suitable tools.

Custom software gives you control over behavior and priorities, but it also makes support, security, deployment and future changes your responsibility. Compare these routes using the same essential requirements. Avoid rejecting an existing tool because it lacks a speculative feature you have not validated.

• Buy when the important workflow is already well supported.
• Configure or integrate when the core product fits and the missing boundary is small.
• Build when the unmet requirement is consequential, specific and likely to persist.

Count ownership, not just construction.

The initial build is one part of the cost. Someone needs to operate the system, respond to failures, update dependencies, manage access and change it as the business changes. A low development estimate that excludes those responsibilities is not a complete comparison.

The benefits need the same discipline. Describe the handling, errors or coordination you expect to change. Use your actual baseline rather than an industry percentage. If the main benefit is a new capability, test whether people need that capability before treating projected usage as evidence.

Make the first release prove something.

A useful first release completes one meaningful journey. It may serve fewer users or fewer cases, but it should include the necessary data, permissions and recovery. A collection of attractive screens cannot validate whether the operating model works.

Choose the assumption most likely to invalidate the project: user need, data access, an integration or a difficult workflow. Test it early. A prototype, a manual trial or a narrow integration may answer the question before a large build becomes justified.

Write the decision in plain language.

Before committing, complete this sentence: we need this system because this specific work cannot be handled adequately by the alternatives, and this is how we will know it helped. Add who owns the system and what the first release must demonstrate.

If that statement still relies on vague growth, innovation or the desire to use a particular technology, return to discovery. The strongest software decisions are understandable to both the person running the business and the person responsible for operating the code.