Read this before you talk to anyone.
Most of what you want to know about a software supplier only comes out on a call, which means you cannot compare it and cannot hold anyone to it. Here it is in writing instead. Nothing on this page is aspirational. Everything on it is something you can hold me to.
How a project actually runs
Every week there is something you can open and click on. Not a status report about something you cannot see yet, not a percentage, not a burndown chart. The working thing, in your hands, from early enough that you can still change your mind about it cheaply.
Each stage is agreed before it starts. That means you are never committed to the whole of a thing you have only seen on paper, and it means the scope conversation happens while it is still a conversation rather than an invoice.
One project at a time
Discovery, design, build and support are one continuous piece of thinking here rather than four handovers between four sets of people. Nothing gets lost in translation because there is no translation.
The cost of that is real and worth saying plainly: there is sometimes a wait. If the answer to when I could start is not the answer you need, you will get that answer on the first call rather than the third.
What you own
The repository is yours, under your account, from the first commit rather than at handover. The services it runs on are in your name and billed to you, so nothing is hostage and nothing has to be migrated later. Documentation is written as the work proceeds, because documentation written at the end is written for nobody.
If the arrangement ends, from either side, you already have everything. There is no licence to keep paying and no platform to be locked into, which means there is nothing to negotiate at the exit and no leverage worth building in.
What support means, including at two in the morning
Support is a real arrangement with real limits, so here are the limits. The systems are monitored and I get told when something breaks rather than waiting for you to notice. Anything that stops people working gets picked up first. Anything cosmetic waits for the next piece of work.
What you will not get from me is a promise of a reply within the hour, around the clock, every day of the year. One person cannot honour that and a promise broken once is worse than a promise never made. What you get instead is a named person who answers, an honest window, and a straight answer about absences before they happen rather than after.
What I do not do
- Hand your project to somebody you have never spoken to.
- Take on work I could not maintain afterwards, because a build I cannot support is a build that is already someone else's problem.
- Build something you could buy. If a product already on the market solves your problem, you will be told that and pointed at it, which costs me the project and saves you the money.
The first step
A scoping session. We go through what the software has to do, what it has to talk to, and what order it should be built in, and what comes out is a written plan of what gets built and in what sequence.
You keep that plan either way. If you take it to another developer, including one who is not me, it still works. It is a useful document rather than a sales artefact, which is the only reason it is worth your afternoon.
The questions people actually ask
- What happens if you get hit by a bus?
- Everything is in your accounts from the start, not mine. The repository, the hosting, the database, the domain. Documentation is written as the work happens rather than promised at the end, so another developer can pick it up by reading it. That is the honest answer to the risk of a small supplier: you cannot remove it, so the arrangement is built so it costs you a handover rather than a rebuild.
- Are you too small for this?
- Ask it about year two rather than year one. Plenty of shops can staff a build. The question is who is still answering in eighteen months when the thing needs changing and the original team has moved on. Queue and Heimdal are both still maintained by the person who wrote them, which is the arrangement you are buying.
- What if I want to bring this in house later?
- Then you take it. There is no licence to keep paying, no platform to be locked into and nothing to negotiate. Your developers get the repository they already own and documentation that was written for someone who was not there.
- Who actually writes the code?
- The person you talk to. There is no account layer, no discovery team handing to a build team, and nothing about your business explained twice.
- What if we change our mind halfway through?
- Businesses do. Anything can be swapped for something of similar size at no charge. Anything that grows the work gets discussed before it starts, never invoiced after it ends.
- Can you work with the developer we already have?
- Yes, and it is often the right shape. Reading and extending someone else's code is a service here rather than a concession.
Tell me the part of the day that is broken.
Start with a scoping session and you keep the written plan either way, even if you hand it to someone else.