How we work
Eight steps, and you always know which one you are on
No month-long silences followed by a reveal. Each stage has a visible output, and each one tells you what is expected from you — because the projects that go wrong are usually the ones where that was never said.
-
Step 1: Discovery
We learn how your business actually works — not how a flowchart says it works. What takes too long, what breaks, what you have already tried.
What we need from you: Talk to us honestly about the messy parts. Those are usually where the value is.
-
Step 2: Scope
We write down exactly what will be built, what it will cost and roughly when. Anything we are not going to build gets written down too, so there are no surprises in either direction.
What we need from you: Read it and push back. This is the cheapest possible moment to change your mind.
-
Step 3: Design
Data structure, screens, and how it fits alongside the systems you already run. For anything with a user interface, you see the layout before it is built.
What we need from you: Tell us where it does not match how your team really works.
-
Step 4: Build
The actual development, in visible increments rather than months of silence followed by a reveal.
What we need from you: Stay reachable for the questions that only you can answer.
-
Step 5: Test
Automated tests, plus deliberate attempts to break it — bad input, missing permissions, the awkward edge cases. We would rather find them than you.
What we need from you: Nothing. This one is on us.
-
Step 6: Customer Review
You use it properly, with real data, before it goes live. We fix what is wrong and adjust what is merely awkward.
What we need from you: Use it the way you actually would. That is what finds the real problems.
-
Step 7: Delivery
Deployment, documentation, and handover. You get the source code, the deployment configuration and instructions written for a person rather than for us.
What we need from you: Confirm you can run it. If you cannot, we are not finished.
-
Step 8: Support
Optional ongoing maintenance, or simply knowing who to call. No lock-in either way — if you want to take it in-house, everything you need is already in your hands.
What we need from you: Decide what suits you. Declining support does not cost you access to anything.
A few things this process assumes
Scope is written down before building starts
Including what is not being built. Most disputes about software are not about quality; they are about two people having assumed different things were included.
Changes are fine, and they have a cost
Requirements shift as you see the thing working — that is normal and often produces a better system. What we will not do is absorb changes silently and then present a surprise at the end. A change gets a price and a decision.
You test it before it goes live
With real data, doing the things you actually do. This step finds the problems that no amount of internal testing will, because we are not the ones who know what Tuesday afternoon looks like in your business.
Handover means you can run it
If you cannot start, stop, back up and restore the system using the documentation we gave you, the project is not finished — regardless of whether the software works.
Tell us what you are trying to fix
The first conversation is thirty minutes, free, and has no pitch in it. We will tell you whether we can help, roughly what it would cost, and if the honest answer is that you do not need us, we will say that too.