Most software doesn't get used. It gets purchased, deployed, trained-on, and then quietly abandoned in favour of the spreadsheet it was meant to replace. The budget is spent, the launch email is sent, and six months later the system logs show fourteen logins from the same IT account.
This isn't a failure of technology. It's a failure of understanding — between the person who commissioned the software and the people who were supposed to use it. Good software engineering doesn't save a product that was conceived around the wrong problem.
Start with the workflow, not the feature
Every meaningful software product is built on top of a human process. Something a person does repeatedly, manually, in a way that takes more time than it should or produces more errors than it could. The feature is the solution; the workflow is the actual problem. We spend more time on the workflow than most clients expect — because the shape of the solution changes completely depending on what the workflow actually is, not what it's described as in a brief.
A logistics company once asked us to build a reporting dashboard. After two hours on their warehouse floor, we learned that the real bottleneck was data entry — reports were only as bad as the numbers feeding them. We built a data capture tool first. The dashboard followed. It got used because the hard part was already solved.
Build for the person who opens it every day
There are usually two sets of people involved in a software procurement: the people who approve it, and the people who have to use it. These groups often have very different priorities. The approver cares about capability, cost and strategic fit. The daily user cares about whether the thing is faster than what they're doing now, and whether it creates new friction or removes existing friction.
Software that serves the approver but inconveniences the user gets worked around. The workaround becomes the real system. If you want software that earns its place, you have to earn the trust of the person who's going to open it every morning.
The question isn't "can we build this?" It's "will people use it when we do?" Those are different questions with very different answers.
Validate the problem before you validate the solution
There's a standard temptation in software projects: to skip straight to wireframes. Wireframes feel productive. They look like progress. But wireframes drawn against an unvalidated problem statement are expensive guesses. We prefer to spend the first stage of any engagement confirming that the problem we're solving is the actual problem — not its polished presentation in a brief.
This means interviews with end users, not just stakeholders. It means watching how existing tools actually get used, not how they were designed to be used. It means being willing to push back on a feature list if the evidence doesn't support it. That pushback is part of the service.
Five questions we ask before writing a line of code
Every project starts with the same five questions — and the answers shape everything that follows.
Who is the primary user, and what does their day look like? Not a user persona. A real person, with a real job title, and a real morning. What does she open first? What's already frustrating her before this product arrives?
What is the one thing this product needs to do better than what exists? Not ten things. One. Everything else is context. If the team can't answer this clearly, the product won't have a clear reason to exist in the user's life either.
What will success look like six months after launch? Not downloads or logins. Actual behavior change. What are people doing differently because this software exists?
What is the migration path from the current system? The most underestimated problem in software adoption is the transition. If the new system requires users to operate two systems at once during changeover, many will quietly revert to the old one and never come back.
What would make someone stop using this? Designing for failure modes is just as important as designing for success. If a slow connection renders the tool unusable, and the primary users work in a warehouse with poor Wi-Fi, that's not an edge case — it's a core design constraint.
Success is measured in habit, not launch
A launch is a milestone, not a measure. Software earns its place over months — when a team stops talking about the old way of doing something, when the system becomes the default rather than the backup, when no one can remember how the workflow ran before it existed. That's the outcome we're building toward on every project. Not a go-live date. A new normal.
