Predictable beats clever.
Most software projects do not fail on technology. They fail because nobody wrote down what "done" meant, progress was invisible until it was too late, and the budget moved without anyone deciding that it should. Our process exists to prevent exactly those three things.
What actually happens.
Understand
We talk to the people who will use the system daily, not only to whoever signs the cheque. We look at the spreadsheets, the current software, the devices and the paperwork. Where possible, we visit.
- Interviews with actual users
- Inventory of systems, devices and data
- A written summary you correct before we go further
Cost: free for a straightforward project. Charged only where a detailed multi-site survey is needed — and quoted first.
Propose
A document, not a slide deck. It says what the software will do, what it will not do, how it connects to everything else, how long it will take, what it costs, and what we are assuming. You approve it before development starts.
- Screen-by-screen scope and user roles
- An explicit "not included" section
- Running costs estimated up front
Why it matters: the "not included" section prevents most disputes. It is the part we spend the longest writing.
Build
Development runs in two-week cycles. At the end of each one there is a working build on a link you can open and click through. You give feedback on something real, not on a description of something.
- A clickable build every two weeks
- Changes re-quoted openly, never absorbed silently
- Riskiest integration tackled first, not last
Your part: one person on your side who can make decisions. Projects slow down when feedback has to travel through a committee.
Launch & support
Where the system is large, one site or one team goes live first and runs for a few weeks before the wider rollout. Then training, documentation, source-code handover, and a support arrangement sized to how critical the system is.
- Pilot before full rollout
- Training for users and for your IT team
- Repository, scripts and documentation handed over
After handover: support is optional. We would like to keep it, but you should be able to leave.
How we make decisions.
These are the rules we apply when there is a judgement call to make and you are not in the room.
We choose well-understood tools with long support lives over whatever is currently fashionable. Your system has to be maintainable in five years, possibly by someone else.
A slipping timeline, an integration that will not work, a requirement that is a bad idea — you hear it from us as soon as we know, not at the deadline.
Poor connectivity, a device that stops reporting, a disk that fills up. Systems are designed to degrade sensibly rather than fail completely.
Decisions, assumptions and architecture go into documents that outlive the conversation. Handover is a document set, not a phone call.
An operator who needs six clicks and a mental checklist will stop using the system. Fewer screens, clearer defaults, and sensible keyboard behaviour matter more than features.
We want you to stay because the work is good, not because leaving is painful. Standard formats, exportable data, documented deployment.
What we need
from your side.
Good projects are collaborations. These four things make the difference between a build that runs smoothly and one that stalls.
One named person who can approve scope and answer questions within a day or two. Not a committee.
Credentials, API documentation and device details for anything we have to integrate with — arranged early, because this is the most common cause of delay.
A sample of your actual records, however messy. Systems designed against tidy invented data break on contact with reality.
If a screen is wrong, tell us in week three rather than at handover. Early changes are cheap; late ones are not.
Start with stage one.
A conversation about the problem costs you nothing and tells us both whether there is a project here worth doing.