Start with the work that must happen
A software decision becomes clearer when you can describe a working day without naming a product. Who starts the process? What information do they need? Who approves the result? What happens when the usual path breaks? These answers give you something concrete to test against an existing product or a custom proposal.
Begin with one important workflow. For example, an ordering process might require a customer to see agreed prices, submit an order, receive approval and follow delivery status. Separate the steps the business depends on from preferences about how a screen should look.
Find the gap before deciding to build
Try the workflow in a candidate product with representative information. Include the awkward cases: a missing customer record, a changed order, a person with limited access. A demonstration of the normal path can conceal the manual work that would remain after purchase. Ask the people doing that work to participate in the evaluation.
Describe each gap precisely. A missing field might be solved through configuration. Re-entering information could call for an integration. A distinctive approval process might need custom software. Also ask whether the process itself should change. Preserving an old workaround in a new system can make unnecessary complexity more expensive to maintain.
Compare three viable approaches
| Approach | A good fit when | What to investigate |
|---|---|---|
| Buy and configure | A product already handles the essential workflow. | Configuration limits, access controls, data export and recurring charges. |
| Extend and connect | Existing systems work, but information or a specific step is missing between them. | Integration access, ownership of shared data and responsibility for changes. |
| Build a custom platform | The essential workflow cannot be served adequately by the available options. | A manageable first scope, ongoing engineering and operational ownership. |
Compare the full responsibility, not only the first invoice
For each option, write down the work required to make it usable: configuration or development, data preparation, migration, integration, training and support. Then consider what changes as usage grows. Licensing, hosting, maintenance and internal administration belong in the same comparison. Use a common planning period and state the assumptions instead of treating an early estimate as a fixed outcome.
Ownership also needs a practical definition. Clarify who can access the code where relevant, export the data, manage infrastructure and change the system. Identify which responsibilities stay with your team. Owning source code does not by itself provide the knowledge or capacity to operate an application. Ask how a future team would understand its structure and continue the work.
A platform can connect a specific view of the business
Nexo’s TempraMed project brings business performance, marketing and customer support into an executive workspace, with connected reporting, an AI analyst and personal dashboards. The platform organizes information around the questions leaders need to answer, from the business overview to the detail behind it.
For your own reporting needs, compare configuring an existing tool with building a focused layer that connects information from the systems you already use. Define what people need to see and do before deciding how much of the surrounding software you need to replace.
Test a small but complete scope
A useful first scope should let a real user complete a meaningful task. Include the necessary information, permissions and exception handling, even if the initial audience is small. A polished screen without the work behind it will not settle the purchasing decision.
Set acceptance criteria before the trial. Can an authorized user finish the task? Can another person see its current status? Can the team identify and resolve a failed step? Record what remains manual and why. Compare the result with the current process, including the effort needed to support the new one.
Bring these questions to the decision
A short decision brief gives internal stakeholders and potential suppliers the same problem to solve. Include the preferred option, the evidence behind it and the uncertainties that could change your choice.
- Which workflow must improve, and what would a successful result look like?
- Which requirements are essential, and which can change?
- What can existing software already handle with configuration or integration?
- Who owns the data, the operating process and future changes?
- What will the first complete scope demonstrate before you expand?
Let’s define the software you actually need.
Tell us about the workflow, the tools you use today and where the work gets stuck.
Discuss your software needs


