Discovery First: Building Software That Actually Gets Used

The most expensive software is not the software that fails. It is the software that ships perfectly, works exactly as specified, passes every test - and then sits unused while the team quietly goes back to Excel and WhatsApp.

It happens constantly. Nobody puts it in a case study. The vendor got paid, the project closed on time, and the business changed nothing. The failure was upstream of the code: nobody did discovery properly.

At Upeosoft, discovery is the first phase of every engagement and the one we refuse to compress. Across 200+ systems delivered, it is the single strongest predictor of whether software gets adopted or abandoned.

What discovery actually is (and what it is not)

Discovery is not a requirements-gathering meeting. It is not a form the client fills in. It is not a sales call with a notepad.

Discovery is the disciplined process of understanding how a business really operates - including the parts nobody documents, the workarounds people are slightly embarrassed by, and the constraints that are political rather than technical. It ends with a shared, written model of the operation and an explicit decision about what to build.

Our four-phase method starts here: Understand, Design, Build, Improve. The Understand phase maps processes, users, workflows, data and success criteria. Everything downstream depends on getting it right.

Why requirements documents lie

Ask a business how their procurement process works and you will get the official version: requisition, approval, purchase order, receipt, invoice, payment. Clean. Linear. Auditable.

Then watch it happen. The branch manager calls the supplier directly because the approver is travelling. The goods arrive before the PO exists. Someone raises the paperwork retroactively on Friday. Finance knows and tolerates it because the alternative is stockouts.

Build software for the official version and you have built software that criminalises the way the business actually survives. Staff will not use it. They will route around it, and your beautiful audit trail will contain fiction.

Requirements describe what people believe should happen. Discovery finds out what actually happens. The gap between them is where projects die.

How we run discovery

Follow the document, not the org chart

We trace real artifacts through the business. Pick one actual sales order from last month. Where did it start? Who touched it? What did they open, type, print, photograph, forward? Where did it wait, and why? A single traced document reveals more than a week of interviews, because it exposes the queues, handoffs and duplicate data entry that nobody thinks to mention.

Talk to the people who do the work

Executives describe intent. Managers describe policy. Only the clerk, the storeman, the driver and the technician describe reality. If discovery only involves the leadership team, you are designing for a business that does not exist.

This is also where you learn what will kill adoption. "It takes four clicks to find a customer" sounds trivial in a workshop. Repeated 300 times a day by someone with a queue in front of them, it is the reason your system gets abandoned.

Find the shadow systems

Every organisation has them: the spreadsheet that actually runs pricing, the WhatsApp group where dispatch is coordinated, the notebook behind the counter, the personal Google Sheet a manager built three years ago that finance now depends on. Shadow systems are not incompetence. They are evidence - each one marks a place where the official system failed to meet a real need.

We catalogue them deliberately. Turning spreadsheets, WhatsApp threads and disconnected tools into one reliable system is literally what we do, and you cannot do it without first finding all of them.

Quantify the pain

Before designing anything, we push for numbers the client already has: how many hours a month go into reconciliation, how often stock counts disagree, how long an approval takes, how many orders are lost or duplicated. Not to build a business case for us - to prioritise. If invoicing takes 40 hours a month and stock counting takes 3, we know exactly where to start.

Define success in advance, in the client's words

Discovery ends with explicit success criteria. Not "improve efficiency". Something testable: month-end close moves from twelve days to four; stock accuracy above 98 percent at the main warehouse; every delivery has a signed digital proof within 24 hours. Written down before we build, so nobody has to argue about it afterwards.

What discovery produces

Discovery is not finished when we feel informed. It is finished when we can hand over a concrete set of artifacts:

• A process map of how the business actually runs today, including the workarounds.
• A user map - who does what, how often, on which device, under what constraints.
• A data model sketch and, critically, an honest assessment of the state of existing data.
• An integration inventory - every system, payment rail, API and file exchange that must connect.
• Success criteria with numbers attached.
• A platform recommendation - standard ERPNext, ERPNext with customization, a custom app, or bespoke engineering - with the reasoning stated.

That last one is where discovery pays for itself immediately. It is the difference between a client buying the right thing and a client buying whatever the vendor happens to sell.

The things discovery catches that nothing else does

Data that is worse than anyone admitted

Item masters with four spellings of the same product. Customer records duplicated across three systems. Opening balances nobody can reconcile. Discovery surfaces this early, when it is a migration plan. Discovered at go-live, it is a crisis and a delayed launch.

Process problems that software cannot fix

Sometimes approvals are slow because the approver has 200 items a week in their queue. No system fixes that; a delegation policy does. A good partner says so instead of quietly building a faster way to do the wrong thing.

Premature technology

Discovery frequently reveals that the thing a client asked for is not the thing they need yet. AI is the most common case right now - a business wants an AI assistant over data that is not yet centralised, clean or complete. The honest answer is to fix the system of record first. We wrote about this in why you should not get pressured into buying AI before your business is ready, and the same reasoning applies to dashboards, BI tools and analytics platforms.

The real constraint

Occasionally discovery reveals that the binding constraint is not software at all - it is warehouse layout, or headcount, or a supplier contract. Finding that out in week two is a gift. Finding it out after a six-month build is a disaster with a signed contract attached.

Discovery is what makes the rest of the work honest

After Understand comes Design - deciding the platform approach. Then Build - clean workflows, reliable integrations, production engineering. Then Improve - rollout support, feedback, reporting, long-term enhancement.

Each phase depends on the one before. Design without discovery is guesswork with a diagram. Build without design is expensive improvisation. And Improve without real success criteria is just a maintenance retainer with no way to prove value.

Discovery is also what lets us say no credibly. When we tell a client that a module is not worth it, or that standard ERPNext already does what they are asking us to build, or that they should spend the budget on data cleanup instead of features, that advice carries weight because it comes from having traced their actual documents through their actual business.

Signs your last project skipped discovery

• Adoption stalled after go-live and shadow spreadsheets came back within a month.
• The system enforces a process that staff routinely bypass.
• Reports exist but nobody trusts them.
• Features were built that nobody uses, while the daily pain point was never addressed.
• Nobody can state what success was supposed to look like.
• Data migration was "handled at the end" and is still not right.

If several of those are true, the fix is rarely a rebuild. It is usually the discovery that never happened, done now, against the system you already have.

Start with a conversation about your messiest process

Upeosoft is a Nairobi-based software company serving businesses worldwide, ERPNext consultancy first and extended with custom engineering across custom software, AI systems and automation, mobile apps and enterprise integrations. If you already run ERPNext, our free health audit UpeoAudit is a good evidence-first starting point.

Bring us the process held together by one spreadsheet and one very patient employee. That is the conversation worth having. Email consult@upeosoft.com, call 0116 888 777, or visit upeosoft.com.