Most software projects start with a demo. Someone watches a SaaS tool presentation, gets excited, buys a subscription, and then spends the next six months trying to make their business fit into it. When it doesn't fit — and it rarely fits perfectly — the workarounds begin. Spreadsheets run in parallel. WhatsApp groups fill the gaps. A junior employee becomes the unofficial "system admin" whose job is translating between the tool and actual reality.
This is the backwards approach, and it is far more common than anyone admits.
The right direction
Software should start with a workflow, not a feature list. Before any tool, platform, or framework comes up, the first question should be: what does this business actually do? Not at a high level. In detail. Who touches a record, in what order, under what conditions? Where does information come from, and where does it need to go?
Only once you understand the workflow can you evaluate whether an existing tool serves it — or whether you need something built specifically for how you operate.
What backwards looks like in practice
- You customise the process to fit the software.Your team stops doing what works and starts doing what the tool supports. Over time, the tool's logic becomes your logic, even when it isn't the right logic.
- Edge cases become manual exceptions.Every process has cases the tool doesn't handle. These get documented in a shared notes file, then forgotten, then rediscovered when the person who knew them leaves.
- Reporting is always almost right.The data is in the system but never quite in the shape you need. Every board report requires someone to export, clean, and reformat before it's usable.
The system becomes a record of compromises rather than a reflection of how the business works.
What forward looks like
When software is built around a workflow rather than imposed on top of one, something noticeably different happens: people use it without being told to. Not because it's beautiful, but because it matches the way they already think about their work. There is no translation layer between reality and the system.
This is achievable with custom software when the brief is right. It is occasionally achievable with off-the-shelf tools when the tool is sufficiently configurable. It is rarely achievable when the selection process started with a demo rather than a workflow.
The one question to ask first
Before any technology decision — before demos, before proposals, before any conversation with a vendor or a developer — write down what happens when a new order comes in, or a new client is onboarded, or an exception occurs. Do it in plain language. Map every handoff. Include the parts that are embarrassing because they still happen on paper.
That document is your real requirements. Everything else is implementation detail.
At Nimbryx, every engagement starts with this conversation — before we talk about technology at all. If you're not sure whether you need custom software or just a better-configured tool, that conversation is worth having. Get in touch.