Separate essential workflow from familiar habits
Write down what users must accomplish, who approves decisions, which records matter and what makes the current process difficult. Separate genuine constraints from preferences inherited from an old spreadsheet. A new product should not need to reproduce every historical workaround.
Ask process owners to demonstrate the difficult cases as well as the normal route. If a modest process change makes a supported product fit, buying may be the stronger option. If the process is strategically important and the workaround creates repeated risk, investigate further.
When an existing product is enough
Off-the-shelf software is a sensible starting point for common, well-understood work. Evaluate permissions, reporting, export formats, integration access, accessibility and support alongside the feature list. Trial the actual workflow rather than accepting a polished demonstration as proof of fit.
Check the edition you need, seat growth, usage limits and how you would leave. Configuration and training still take effort. A subscription becomes poor value if staff maintain a second system outside it because essential work remains unsupported.
Integration is a third option
You do not have to choose between replacing everything and tolerating duplicate entry. An integration or a narrow internal tool may connect the products that already work. Keep accounting, identity or other standard capabilities in established systems where that remains appropriate.
Published examples include a compliance system integrated with Sage 200 and Monday.com, and an automotive CRM connecting ten existing APIs. They illustrate different ways of joining operational work; they do not prove that every business needs a custom CRM or a replacement platform.
When a bespoke build earns consideration
Consider a build when important workflows cannot be supported safely by configuration or integration, when several departments need one coherent operational view, or when the capability is central to your product. Be specific about what the business gains and what responsibility it accepts.
Start with the first useful slice, not a complete replacement specification. Agree roles, data migration, acceptance checks and deployment boundaries. Review working software with the people who will use it before expanding the scope.
Compare lifetime cost and an exit route
Compare licences, setup, integrations, staff training and future price changes against design, development, hosting, maintenance and support. Include internal time on both sides. There is no universal break-even point: model your users, expected changes and operational consequences rather than borrowing a market rate.
For a build, ask about source-code ownership, documentation, backups, access and who can maintain it if the original developer leaves. For a product, test data export and replacement options. At Fewzen, builds are scoped stage by stage; a project conversation can establish the first scope without requiring an Opportunity Review.