1. Discovery
We work out what you are actually trying to achieve, which is regularly not what the initial brief describes. This is where we do most of the arguing, and where we occasionally talk somebody out of a project. We would rather lose this one and be trusted for the next than build something we could see was wrong.
- Conversations with the people who will use the thing, not only the people buying it
- Reading the systems that already exist, including the spreadsheets nobody mentions
- An honest assessment of whether something off the shelf would serve you better
- Output: a written scope, a fixed price and a date
2. Scope and design
Structure, data model, interfaces and the technical decisions that are expensive to reverse. Permissions and audit are designed here rather than added later, because retrofitting a permission model is the most expensive rework in software. For websites this is where the content is worked out, because content is the critical path and pretending otherwise is why projects slip.
- Data model and permissions designed before anything is built on top of them
- Interface design against real content, not filler
- Technical decisions written down with their reasoning, for whoever inherits this
- Anything we are unsure about tested cheaply before it becomes structural
3. Build
Work ships continuously to an environment you can see, and you see it every week. There is no phase where we disappear for three months. You talk to the people writing the code — there is no account manager translating between you and them, because translation is where requirements go to die.
- A running environment you can use from the first weeks, not a demo at the end
- Weekly contact with the people actually building it
- Automated tests on the paths where being wrong costs money
- Monitoring and logging wired in during the build, not bolted on at the end
4. Launch
Launches are rehearsed. For anything replacing an existing system that means a tested rollback, a data migration run against a copy of production more than once, and a cutover sequence designed around your business rather than our convenience. For websites it means URL mapping and redirects agreed before launch, because the classic redesign failure is a traffic collapse four weeks later.
- A rehearsed cutover with a rollback that has been tested, not merely written
- Redirects and URL mapping in place before launch for anything replacing a site
- Monitoring on errors, performance and the numbers that matter from hour one
- Someone available during and after the launch window, named in advance
5. Operate, or hand over
Either we run it or your team does, and both are fine. What we will not do is leave you with something nobody understands. The runbook is written for a competent person who was not on the project, because eventually that is who will be reading it — and sometimes that person works for you.
- A runbook written for whoever operates it next, including the case where that is not us
- Infrastructure as code, so the environment can be rebuilt rather than remembered
- Agreed response expectations, in writing, if we are operating it
- A documented handover path, available whenever you want to take it in-house
Tell us what you are trying to do
A short conversation is usually enough to tell whether we are the right people. If we are not, we will say so and point you somewhere better.