Build vs buy: internal business software for SMEs

Define the operational gap first

Describe the work that is failing rather than beginning with a preferred product. Identify users, decisions, data, handoffs and the consequence of the current gap. This separates a real application need from frustration with poor configuration or adoption.

If the business cannot agree on the process, custom development will encode disagreement into software. Clarify the operating model before choosing the technical route.

Buy or configure when the process is common

Established CRM, finance, project and service platforms have already solved many standard requirements. Buying is usually stronger when the workflow is common, compliance updates matter and the product covers most needs without extensive workarounds.

Configuration, training or removal of unnecessary fields may resolve the issue. Include migration, licences and adoption in the comparison rather than judging the product only from its headline subscription.

Integrate when the tools are individually useful

Sometimes no new application is needed. Connecting enquiry, CRM, operations and reporting tools can remove duplicate work while letting each platform continue doing the job it handles well.

Integration is most appropriate when the missing value is the handoff or shared visibility, not a completely new user experience.

Build when the workflow creates distinctive value

A custom application becomes credible when the process is important, stable enough to define and poorly served by available tools. It may provide a focused operational portal, approvals, evidence capture or a role-specific interface over existing systems.

The first release should remain narrow. Rebuilding every feature of a mature platform increases cost and support responsibility without improving the distinctive part of the workflow.

• The workflow is central to how the business delivers value.
• Existing tools require persistent manual workarounds.
• Users need a specific, simpler operating view.
• The data and ownership model can be defined.
• The business accepts ongoing product ownership.

Compare lifetime ownership and exit routes

Buying creates vendor dependency, licence changes and product constraints. Building creates responsibility for hosting, security, updates, documentation and future development. Neither is inherently safer or cheaper.

Ask how data can be exported, who owns source code and accounts, what happens if support ends and how integrations are documented. An exit route is part of a responsible decision.

Use a scored decision and a prototype where needed

Score each route against functional fit, implementation risk, time, lifetime cost, adoption, security, control and maintainability. Where uncertainty is high, test the hardest assumption with a small prototype instead of committing to a full application.

A good recommendation may be buy, integrate, build or simplify the process. The aim is the most proportionate operating system, not custom software for its own sake.