Requirements First: Why We Map Every Workflow Before We Build
Most software projects for small and mid-sized businesses go wrong before any code is written. Here is how we map the paper, spreadsheet, and WhatsApp process first, agree the scope in writing, and only then build.
By Shuvam, Founder of KodeBiz · Updated 30 Sept 2026
Why SME software projects go wrong before the build
Most software projects for small and mid-sized businesses do not fail because the code is bad. They fail because building started before anyone understood the work. A vendor sees a shared spreadsheet, hears 'we need a CRM', and starts designing screens. The real process, with its exceptions, its informal approvals, and the one person who knows why a column exists, only surfaces once the system is half built.
By then every discovery is expensive. A missed approval step means reworking permissions. A field nobody mentioned means migrating data twice. And a team handed a system that does not match how it works quietly goes back to the paper register, the spreadsheet, or the WhatsApp group.
- The documented process is not the real one: the policy says one thing, the team does another
- Exceptions stay invisible until they break the new system
- Approvals live in people's heads, email threads, and chat messages
- Data that has to migrate is found late, after the data model is fixed
How a requirement study works
A requirement study starts with the people who do the work today, not with a feature list. We sit with the sales rep, the billing clerk, the branch manager, and whoever maintains the register, and follow the work as it actually moves: where it is written down, who it is handed to, and what happens when something goes wrong.
Everything the new system will have to handle gets written down, including the parts nobody thinks to mention because they have always been done by hand.
- The current process, step by step, across paper registers, shared spreadsheets, WhatsApp follow-ups, and email approvals
- Every exception: the urgent order, the disputed invoice, the approver who is out of office
- Approvals: who signs off on what, in what order, and what happens when they do not respond
- Roles: who needs to see, create, edit, or approve each kind of record
- Reports the business relies on today, and the ones it cannot produce at all
- Data that has to migrate: which records, from which files, and who confirms they are clean
What the study uncovers in practice
At Ceiling Impex, the sales team ran its pipeline on a shared Excel lead register across 11+ branches. The study surfaced problems no feature list would have: stage labels had drifted ('Negotiating', 'In negotiation', 'Discussing'), so nobody could roll up a pipeline number, and deals that closed lost were deleted rather than kept. Those findings became requirements: a fixed set of configurable stages, scoped views for reps and managers, and a full audit history so nothing disappears.
At King Stubb & Kasiva, a multi-office law firm, the study followed an invoice from draft to client. Drafts moved between lawyers and partners who were rarely in the same office, and an invoice could stall while a partner was in trial in another city. The requirement that came out of it was a four-step approval chain, drafter to senior lawyer to managing partner to billing, with a reminder whenever a step is stuck. Built on Power Automate, that chain took invoice turnaround from 12 days to 2.
For a manufacturing distributor that needed a Section 138 cheque-bounce case manager, the study meant sitting with the operations and legal team and mapping how a bounced cheque really moved from bank return to legal notice to complaint, rather than how the policy document said it should. The statutory windows, the handoffs, and the points where a date could slip were all on paper before design began.
Agreeing the scope in writing before development
The study becomes a written scope that the client reviews and agrees before development starts. Design and build begin only once it is signed off, and every milestone after that is reviewed against it. The question at each review is not 'is this what you meant?' but 'does this match what we agreed?'
That only works if the scope is specific enough to check the finished system against, line by line. It covers:
- Screens: every form, list, and dashboard, with the fields each one carries
- Workflows: each step, its approvals, and what happens on an exception
- Roles: who can see, create, edit, and approve each kind of record
- Reports: the numbers the business needs and where each one comes from
- Data migration: what moves from the old registers and spreadsheets, and how it is checked
- Integrations: Microsoft 365, email, sign-in, and any existing system the new one must talk to
Handling changes once the scope is agreed
Requirements still change. A new approval step appears, a report turns out to need another field, one branch works differently from the rest. Writing the scope down does not stop change. It makes change visible.
When something new comes up, we record it as a change request: what is changing, why, and what it affects in screens, workflows, data, and effort. The client decides whether it goes in now, waits for a later phase, or is dropped. Nothing is added quietly, so the scope stays an accurate description of the system being built and the milestone reviews stay meaningful.
After go-live: testing, training, and support
Before go-live, the system is tested against the agreed scope and against the real cases collected in the study: the exceptions, the approval paths, the migrated records. People are trained on their own workflows, the ones they described during the study, rather than on a generic walkthrough.
After go-live, we stay on for support: fixing issues, answering questions, and adjusting the system as the business changes. The written requirements keep paying off here, because support starts from a shared record of what the system is meant to do. The Section 138 case manager computes every statutory deadline from rules mapped with the client's legal team, and it has run with zero missed statutory deadlines since go-live.
- Testing against the agreed scope and the real exceptions found in the study
- Migrated data checked and signed off by the people who kept the old records
- Training by role, built around each team's own workflows
- Ongoing support after the old register or spreadsheet is retired
Most SME software goes wrong before the first line of code, when building starts ahead of understanding. Sit with the people who do the work, document every step, exception, and approval, agree the scope in writing, and only then build, test, train, and support.
Frequently asked
What is a requirement study?
It is the first stage of every build. We sit with the people who do the work today, map the current process across paper registers, spreadsheets, WhatsApp, and email, and document every step, exception, approval, role, report, and record that has to migrate. The output is a written scope the client reviews and agrees before development starts.
Why not start building and adjust as we go?
Because most of what makes an SME's process hard is invisible from the outside: informal approvals, exceptions, and data spread across files and chat threads. Building before those are understood means discovering them inside a half-built system, where every change costs more. Mapping the work first means the system is designed around how the business actually runs.
What happens if our requirements change after the scope is agreed?
Changes are expected. Each one is written up as a change request that says what is changing, why, and what it affects, including effort and timeline. You decide whether it goes in now, moves to a later phase, or is dropped. Nothing is added without agreement, so the scope always matches the system being built.
What support do we get after go-live?
Testing against the agreed scope before launch, training for each team on its own workflows, and ongoing support once the old spreadsheet or register is retired. Because the requirements are written down, support starts from a shared record of what the system is meant to do rather than from memory.