Most companies should buy software before they build it. Mature products already solve common needs such as accounting, customer support, payroll, identity, and document signing. Rebuilding those capabilities creates cost without differentiation.
But “buy before build” is a starting rule, not a permanent answer.
There is a point where another configurable platform no longer simplifies the operation. It becomes another place where people translate the business into someone else’s model.
Buy the commodity, examine the workflow
The useful distinction is not standard software versus custom software. It is commodity capability versus distinctive workflow.
Email delivery is a commodity capability. The exact sequence by which your team qualifies a request, applies policy, handles exceptions, updates several systems, and assigns the next owner may be distinctive.
A strong internal tool rarely replaces every product involved. It coordinates the part that is specific to the business while allowing mature systems to keep doing what they do well.
This leads to a practical pattern:
- buy the system of record
- integrate the commodity services
- build the operational layer that reflects how the company works
Signs configuration has become a workaround
Configurable platforms are valuable, but configuration can quietly become software development with worse tools.
Watch for these signals:
- fields are repurposed because the correct concept does not exist
- teams maintain separate spreadsheets to explain what the platform cannot show
- automations are chained together without clear ownership or testing
- a simple policy change requires edits in several unrelated places
- only one person understands how the configuration works
- staff copy data between products to keep states aligned
None of these proves that custom development is necessary. Together, they suggest the current system is imposing a model that does not fit the operation.
Calculate coordination cost, not only license cost
The price of software is visible on an invoice. The cost of adapting work around software is distributed across the team.
Consider how much time is spent:
- checking whether information is current
- explaining a request to the next person
- correcting data entered in the wrong place
- rebuilding context after an exception
- maintaining fragile no-code automations
- training people on workarounds that exist only because of tool limitations
An internal tool is justified when reducing those recurring coordination costs creates more value than the tool costs to build and operate.
The calculation should include ongoing ownership. Custom software needs monitoring, security updates, documentation, and someone accountable for its behavior. If the business is not prepared to own a system, it should not build one.
Build the smallest operational surface
The first version should not attempt to become a complete platform.
Start with the narrow surface where people need shared context and action. It might show a queue of requests, the current owner, relevant data from connected systems, and the decisions available at that stage.
The underlying systems can remain in place. The internal tool becomes a coherent working surface over them.
This approach reduces risk because it preserves existing records and services. It also lets the team validate whether the new workflow actually improves the operation before expanding the system.
A decision framework
Buying is usually preferable when the process is standard, the market offers mature options, and adapting the business does not create meaningful friction.
Building becomes more reasonable when:
- The workflow is important and repeated frequently.
- Its exceptions and rules are specific to the business.
- Existing products require costly workarounds.
- The system can create clear operational leverage.
- The company is willing to own it after launch.
The best answer is often both: buy dependable capabilities and build only the connective operational layer.
Custom software should not exist because a team dislikes a user interface. It should exist because the business has a valuable way of working that generic software cannot support cleanly.