What should determine the buy, configure or build decision?
Start with the workflow, its consequences and the parts that genuinely distinguish the business. Buy when the need is common and a product fits without harmful compromise. Configure when a platform provides the right foundation and variation is bounded. Build when the workflow creates meaningful advantage, carries unusual constraints or cannot be supported responsibly by available products. Use the least bespoke option that survives this test.
Separate ordinary capability from business difference
Authentication, document storage, email delivery and routine accounting are usually established capabilities rather than reasons to own new software. Pricing logic, operational sequencing or customer service may be differentiating if they express how the business competes. Mark each requirement as commodity, configurable variation or genuine differentiation before discussing products or technology stacks.
Describe the consequence of compromise
A workaround is acceptable when it is infrequent, visible and cheaper than changing the system. It becomes a poor fit when staff repeatedly re-enter data, customers receive inconsistent outcomes, controls depend on memory or growth multiplies manual work. Estimate the operational consequence of adapting the business to the software, not just whether a feature appears on a comparison page.
When is buying an existing product the strongest choice?
Buying is strongest when the process is well understood across the market, the product satisfies the important journeys, integrations are credible and the vendor's operating model matches the business. The value comes from sharing development, security and maintenance across many customers. The business still needs to evaluate data control, exit options, service limits, price behaviour and the effort required to adopt the product properly.
Prefer a mature answer to a common problem
Payroll, bookkeeping, customer support and common collaboration needs often benefit from mature products with established controls and continuing updates. Rebuilding a familiar category creates ongoing responsibility without necessarily creating an advantage. A bought product is especially compelling when the business can adopt its model without distorting an important workflow.
Test the operating fit, not only the demonstration
Use representative data and complete journeys during evaluation. Check permissions, exports, integration behaviour, failure handling, support, regional needs and the limits of each plan. A polished demonstration may use clean examples and administrator access that do not resemble daily work. The relevant question is whether normal staff can operate the product under real constraints.
Understand the dependency being accepted
Buying exchanges implementation responsibility for vendor dependency. Review how data can be retrieved, how prices may scale, which capabilities require higher tiers and what happens if the service changes or closes. Dependence is not automatically undesirable; it should be visible, proportionate and easier to manage than owning the capability directly.
When does configuring a platform make sense?
Configuration makes sense when the business needs a proven foundation but has bounded differences in forms, approvals, roles, data or integrations. It can deliver more fit than a fixed product without creating an entire product from scratch. The decision is sound only if important behaviour can be expressed through supported configuration rather than fragile scripts, duplicated records or continual specialist intervention.
Define where configuration should stop
List which variation the platform is designed to support and which changes require custom code or external services. A small amount of extension can be useful, but extensive work around a mismatched core produces the cost of custom software with less control. Treat each plugin, automation and bespoke connector as something that must be tested and maintained through platform updates.
Protect a coherent source of truth
Configuration projects often become difficult when several tools each hold a partial version of the same customer, order or case. Decide which system owns each record and which events move information between systems. A platform is valuable when it simplifies the operation; adding layers of sync and reconciliation to imitate a missing core workflow is evidence that the foundation may be wrong.
What justifies building custom software?
Custom software is justified when a consequential workflow is specific to the business, available products impose damaging constraints, or the organisation needs control that cannot be obtained through configuration. The case should name the operational or commercial outcome that ownership enables. Custom work also transfers responsibility for security, reliability, support and evolution to the business and its delivery partners.
Build the differentiating layer, not every dependency
A custom product can still use established services for identity, payments, messaging, hosting and other commodity capability. Owning the workflow does not require recreating the whole technology stack. Deliberate use of mature components concentrates bespoke work where the business needs control and reduces the amount that must be maintained alone.
Require evidence stronger than frustration
Dislike of an existing product does not prove that a custom replacement will be better. Observe the work, quantify repeated constraints, examine alternatives and prototype the riskiest assumption. The case becomes credible when the team can explain what must improve, why available products cannot achieve it and how the proposed system will be operated after launch.
How should a business compare the full cost of each route?
Compare the whole operating life: evaluation, licences, configuration, migration, integration, training, support, change, security, downtime, internal ownership and eventual exit. Use a realistic time horizon and show uncertainty rather than manufacturing a precise total. Then choose the option that provides the required outcome with an acceptable dependency, change path and concentration of responsibility.
Include the cost of work outside the invoice
Staff time spent reconciling systems, maintaining workarounds or waiting for vendor changes is part of the decision. So are internal product ownership and technical support for a custom system. Compare scenarios using the same volume, growth assumptions and service expectations so a subscription and a development estimate are not judged on fundamentally different bases.
Consider a deliberate combination
Many sound systems combine the three routes: bought commodity services, a configured operational platform and a small custom layer for the differentiating workflow. The boundaries must remain understandable and the business record must have a clear owner. A combination is useful when it reduces bespoke work; it is harmful when it hides a fragmented operation behind more integrations.
Make the decision reversible where possible
Record the assumptions, evidence and conditions that would change the choice. Preserve data access, use stable interfaces and avoid unnecessary dependence on undocumented behaviour. Twofold's architecture and discovery work can help map the workflow and compare the routes before a large commitment turns an early preference into a long-term constraint.