How we work
Most software projects fail in the same three ways: the scope was never written down, nobody saw anything working until it was too late to change, and the person who built it disappeared afterwards. Our process exists to close those three holes.
The six stages
Understand
We sit with the people who do the work, not only the people who sign the cheque. The person entering the data knows where the process actually breaks, and they are usually the last person consulted.
Scope
A written document: every screen, every user role, every report, what is in and what is explicitly out. You read it, you argue with it, you sign it. Nothing gets built from a conversation.
Design
Clickable screens before anything is built. Changing a screen costs an afternoon; changing built software costs a fortnight. This is where you should be difficult.
Build
In stages, with something working to look at every two weeks. You are never waiting three months to discover the project went wrong in week two.
Go live
Data migrated and reconciled against your existing records, staff trained in small groups, and we stay close through the first month — which is when the real questions arrive.
Support
Fixes, changes and improvements as the business changes, with a named contact rather than a ticket queue nobody owns.
What we need from you
The part nobody tells you, and the part that decides whether a project runs on time.
One decision-maker
Not a committee. Somebody who can approve a screen without three meetings. Projects slip on approval time far more often than on development time.
Access to the people doing the work
A few hours with the storekeeper, the accountant and the site supervisor is worth more than a week with a consultant’s requirement document.
Your real data, early
Not a clean sample. The actual export, with the duplicates and the blank fields and the three spellings of the same supplier. Migration surprises are the commonest cause of a delayed go-live.
Honesty about what will not change
If a process exists because of a person rather than a reason, tell us. We will build around it rather than pretending it will go away.
When the scope changes mid-project
It will. Every project we have run has changed shape somewhere in the middle, because businesses do not stand still for four months while software is written.
What matters is that it is handled openly instead of quietly absorbed until somebody runs out of goodwill.
Anything that adds real work gets written down as a change request with its own cost and its own effect on the date, and you decide whether it is worth it before we do it.
Nothing gets built because somebody mentioned it on a call. Nothing gets billed that you did not approve. And we will tell you when a change you are asking for is a bad idea — that is part of what you are paying for.
Questions about working with us
How do you price a project?
Against a written scope, agreed before any code is written. We do not publish indicative figures, because the same-sounding requirement can differ several times over in cost depending on the specifics.
What drives the number: how many distinct user roles there are, how many screens and reports, how much data has to be migrated from existing systems, how many other systems it must talk to, and whether your process is already documented or has to be worked out first. A first conversation is usually enough for us to tell you the rough order of magnitude.
How long does a project take?
It depends on how much of the system you want live at once, which is why we usually suggest starting with one module rather than everything.
What holds true regardless is the shape of it: you see something working every two weeks from the start of the build. You are never waiting three months to find out the project went wrong in week two.
What happens if our requirements change halfway through?
They will, and that is normal. What matters is that it is handled openly instead of quietly absorbed until somebody runs out of goodwill.
Anything that adds real work gets written down as a change request with its own cost and its own effect on the date, and you decide whether it is worth it before we do it. Nothing gets built because somebody mentioned it on a call, and nothing gets billed that you did not approve.
Can we start with one module and expand later?
Yes, and for most businesses it is the better way in. A first module that is live and working tells you more about whether we are the right people than any proposal does, and it limits what you risk finding out.
The one condition is that the whole system is designed at the start even if it is built in stages, so the second module does not require the first to be rebuilt.
How do you stop our staff from going back to Excel?
By building it around what they already do, and by talking to them during the scope stage rather than only to the person signing the cheque. Most systems are rejected because they add work for the people entering the data while the benefit lands somewhere else.
Practically: fewer screens, fewer mandatory fields, capture what can be captured automatically, and make the daily task faster than the spreadsheet it replaces. Then train in small groups and stay close for the first month, which is when the real questions arrive.
Who owns the source code?
You do, on final payment. Source code, database, documentation and intellectual property in the work are assigned to you in the contract. There is no licence that expires and no situation in year three where you discover the software is not yours.
We also hand over in a usable state: documented, commented, and written so another developer can pick it up.
Tell us what isn’t working
A first conversation costs nothing and commits you to nothing. Bring the problem — the mess of spreadsheets, the report nobody can produce, the process that breaks every month-end. We will tell you honestly whether custom software is the answer, and roughly what it would take. Sometimes the answer is that you do not need us. We will say so.