When to build custom software — and when not to.

Useful signals and false positives

Useful signals and false positives

A complex spreadsheet does not automatically prove the need for software. It may indicate an unclear process, a necessary control or simply a temporary stage.

Stronger signals are stable repetition, meaningful error cost, a need for shared state and an advantage that standard tools cannot support without continuous workarounds.

• Rules stable enough
• State shared by several roles
• Errors costly or difficult to recover
• A genuinely specific operating difference

Improve, configure, compose or build

Improve, configure, compose or build

The first option is to remove unnecessary steps. The second is to configure an existing tool. The third composes products and integrations. Only the fourth creates and maintains proprietary software.

The choice should not be ideological: different parts of the same system can use different levels. A custom interface can rely on standard services; a standard process may need one small proprietary component.

Assess the lifecycle, not only the first build

Assess the lifecycle, not only the first build

Real cost includes clarification, testing, security, migrations, support and future decisions. Someone must be able to choose priorities and accept trade-offs over time.

A bounded pilot is useful when it can test the central risk without pretending to be a complete product: one critical rule, an end-to-end journey or a surface used by a limited group.

Replicating the existing process in code

Replicating the existing process in code

Encoding every exception freezes complexity that may need removing. Before interface work, distinguish rules, habits and genuinely necessary cases.

Another mistake is postponing audit, permissions and rollback. If software changes data or enables actions, these contracts belong to the initial product, not an undefined later phase.

When to buy or configure

When to buy or configure

If the process is common, differentiation is low and a product covers most requirements, configuration reduces risk and time. Reversibility matters too: leaving a standard choice is often easier than maintaining code without ownership.

Do not build when nobody can govern priorities, data and change. The problem is not technology but the absence of product ownership.