Start with the spreadsheet nobody mentions

In almost every organisation there is a spreadsheet that is not supposed to exist. Somebody maintains it because the official system cannot do a thing the job genuinely requires. That file is the most honest piece of documentation in the business, and it is usually the correct specification for whatever should be built.

Software fails when it is designed against the process diagram rather than the work. The diagram describes what should happen. The spreadsheet describes what does. Building for the second one produces tools people actually open.

Watch the work before designing anything

Sit with the team for a day. Note every point where information is copied from one place to another, every moment somebody hesitates, and every workaround presented with an apology. Those three signals will tell you more than a month of requirements gathering, because they are behaviour rather than opinion.

Build the smallest useful version first

The projects that succeed put something imperfect in front of real users early, on real work, and then improve it weekly. The projects that fail spend six months producing something complete and discover on launch day that the second screen was the wrong shape.

Smallest useful means genuinely usable, not a demo. One team, one workflow, real data, real consequences. That is where the honest feedback lives, and honest feedback is the only thing that reliably improves software.

The spreadsheet nobody was supposed to build is usually the specification you were looking for.

What we typically build

• Internal tools that replace the private spreadsheet, with the same flexibility and none of the risk.

• Client portals so status questions answer themselves instead of arriving by email.

• Integrations between systems that already run the business, so information is captured once.

• Reporting that produces the number somebody currently assembles by hand every Monday.

• Admin interfaces for the team, designed with the same care as anything a customer sees.

Handover is part of the build

A tool nobody was taught is a tool nobody uses. We run the handover in person, with the people who will use it daily, on their own work rather than a sample. The session usually surfaces two or three small improvements worth more than anything on the original backlog.

1. A working session where the team uses the tool on live work while we watch.

2. Documentation written for the person doing the job, not for a developer.

3. A short list of known rough edges, so nobody has to discover them alone.

4. An agreed route for changes, so improvements keep happening after we leave.

None of this is glamorous. It is the difference between software that becomes part of how a business runs and software that quietly gets abandoned in favour of the spreadsheet it was meant to replace.