How we work
What actually happens, and what it costs.
Most firms will not tell you this before you are already talking to a salesperson. It is not commercially sensitive and it is not complicated — it is just rarely written down, which is itself part of why buying software feels the way it does.
Why this way
The problem is not that software is hard to build.
It is that most people buying it cannot tell whether they are getting what they asked for until the money is spent. You describe a business problem; you get back a number, a timeline and a set of words you have no way to check. If it goes wrong, it goes wrong late, and by then the argument is about what was meant rather than what was agreed.
So the first thing we produce is not code. It is a written description of the system in your own language, detailed enough that you can hand it to the person who does the job every day and have them tell you where it is wrong. Everything else — the price, the schedule, when something counts as finished — is attached to that document.
That is the whole trick, and it is not a clever one. It just means the expensive misunderstanding happens in week two, on paper, instead of in month six, in code.
The work
Five phases, in order.
How long the whole thing takes depends entirely on what it is, and anyone who gives you a number before the first phase is guessing at you rather than for you.
- 01
We work out how it actually runs
A few conversations with the people who do the work, not only the person paying for it. What really happens, where the exceptions live, what everyone works around, and which system is believed when two of them disagree. This is where most of the surprises are, and finding them here is much cheaper than finding them later.
- 02
We write the specification
A document in your language describing the system: what gets recorded, who can see what, every process end to end, what each person uses day to day, what it connects to, and how we will both agree a thing is finished. No architecture diagrams, no framework names — those are our problem, not yours.
- 03
You go through it and sign it off
Read it, mark it up, hand it to whoever knows the bits you don't. Expect to send it back at least once — the ones that come back unchanged usually mean it was not read. We start when it says what you actually want.
- 04
We build it in pieces you can see
Not one long silence ending in a reveal. Work goes in order of what the specification says matters, and you see something running early enough to change your mind while changing it is still cheap.
- 05
We put it into production and hand it over
Deployed, monitored, documented, on accounts in your name. Handover is a scheduled piece of work with your people in the room, not a zip file and an invoice.
Money
How pricing works.
Written plainly, because the alternative is that you find it out one clause at a time.
The specification is priced on its own
It is a piece of work with its own cost, and it is yours whatever happens next — including if you take it to someone else. We would rather lose the build than have you buy one you could not evaluate.
The build is a fixed price against it
The number attaches to the signed document, not to an estimate of hours. If we get our estimate wrong, that is our problem to absorb, which is the correct way round.
Changes are quoted before they happen
Anything outside the signed scope comes back to you with a price and a schedule impact before any work goes into it. No change appears on an invoice you have not already agreed to.
No open-ended retainer
If you want us to keep working on it afterwards, that is a new agreement with its own scope. Support and hosting, if you want them from us, are priced separately and are not a condition of anything.
When it goes sideways
What happens when something doesn't go to plan.
It will, in some small way, on every project. What matters is which of us it costs, and whether that was decided in advance or argued about afterwards.
If we estimated badly
The fixed price holds. That is what fixed means, and it is the reason we spend real time on the specification instead of guessing quickly.
If you change your mind mid-build
Normal, and often a sign the first phase worked. You get the cost and the schedule impact, and you decide. Some changes are free because they are cheaper than arguing about them.
If you want to stop
You keep everything built and paid for to that point, plus the specification. There is no clause that makes leaving expensive, because a client who stays only because leaving is painful is not a reference.
If we are the wrong people
We will say so, ideally in the first conversation and at the latest at the end of the specification. Turning down work we would do badly is cheaper for us than doing it.
The end of it
What changes hands at handover.
Handover is a real piece of work with a date on it, not the moment we stop answering email.
You get
- The source code, in a repository on your account
- The running system, on infrastructure in your name
- Every credential, key and login, transferred to you
- Documentation written for whoever maintains it next
- A session with your people, recorded, so it survives them leaving
Which means
- You can hire someone else tomorrow and they can pick it up
- You can move it to another host without asking us
- Nothing stops working if we stop existing
- Keeping us is a decision you make each time, not a default
- We have to stay useful, which is the correct incentive
Still want to know something specific?
Ask. If it is about how we work rather than about your project, you will get an answer without a call attached to it.