Start with the workflow that creates friction. An existing product is often the right starting point when it fits your process. A custom build makes sense when the gap is important enough to justify ownership, testing and maintenance.
Write down the real process
Follow one item from start to finish: a new lead, an order or a project. Record who handles each step, where information lives and when someone has to copy it into another tool. Include exceptions such as cancellations, reassignment and incomplete information.
A short process map and anonymised examples are more useful than a feature wish list. They reveal whether the problem is a missing system, an awkward connection or an unclear operating rule.
Test the smallest existing option first
Check whether a product handles the critical workflow using supported configuration. Assess permissions, exports, integrations and the daily experience for your team. Many fragile workarounds may cost more to operate than the subscription suggests.
For standard task tracking or routine follow-up, a product may reduce setup time. Ask what happens when the team grows, a role changes or you need to move your data elsewhere.
Build when the difference matters
Custom development becomes useful when the workflow is distinctive, several systems must share information, or access rules and reporting do not fit available tools. Solve a defined operating problem before recreating a large software suite.
Choose one workflow, agree what a successful result looks like and test it with the people who do the work. Add the next workflow after the first is being used reliably.
Compare the full cost of ownership
Include setup, data cleaning, migration, training, integrations, subscriptions and support. For custom software, agree who owns the code, infrastructure, documentation, backups and future changes.
Ask for explicit inclusions, exclusions, dependencies and acceptance checks. Delivery time and price should follow the agreed scope. A headline price without those details is difficult to compare.
Prepare a useful first brief
Bring your current tools, three process problems, the roles involved, the information you need to see and any launch deadline. Share sample formats with sensitive information removed. OMX can then discuss whether a product, an integration or a custom build fits.