What happens
after you say yes.
Nearly everyone has been burned by a supplier who went quiet once the deposit cleared. So here is the whole of it up front: what we do, when we do it, what we need from you, and how you get every key back at the end.
Nothing starts until the boring parts are done.
Nothing gets built before the paperwork is signed and the access works. That sounds like bureaucracy and it is the opposite: an engagement that opens with a fortnight of “still waiting on the DNS login” spends all its goodwill before producing anything. How long the build itself takes is set in the spec you approved, which makes it the one number on this page we cannot print in advance.
Within 5 days of signing
Kickoff
An hour with everyone from discovery, plus whoever holds the keys to your systems. We walk the build spec one last time — this is the last free moment to say “that is not quite how it works” — and the access requests get started live on the call, not emailed to you as a list afterwards. A written summary lands the same day.
What we needThree names: who decides, who does the work, and who holds the logins.
First week
Something to look at
By the end of week one there is a URL you can open. It will be visibly unfinished, which is exactly what it is for: it turns an invoice into something you can look at, and it surfaces misunderstandings while they still cost nothing to fix.
What we needAccess, per the checklist we start on the kickoff call.
Through the build
A rhythm you can set your watch by
A written update the same day every week, including the weeks when nothing moved — those especially. A half-hour call you are welcome to skip. Staging you can open whenever you like, without asking. If a date is going to slip, you hear it in the next update, not the one after it.
What we needAnswers within a couple of days, and your content by the date we agreed.
Whenever it comes up
Changes, priced before they happen
Changing your mind halfway through is normal and we plan for it. Anything outside the spec gets written down, priced, and approved by you before a line of it is built. Nothing is quietly absorbed, and nothing appears as a surprise on an invoice.
Before it goes live
You use it first
This is not a demo. Whoever is going to live in the thing does a normal piece of their work in it while we sit quietly and take notes. Most of what is worth changing surfaces in that hour, and nothing goes live before it has happened.
What we needAn hour of the person who will use it most, and sign-off in writing.
One morning
Go-live
A Tuesday or Wednesday morning. Never a Friday, never the day before a holiday, and never while the person who depends on it is away. Someone watches the first hour. The rollback is written down before we begin. Every path gets walked by hand on the live system inside a day.
Handover week
It becomes yours
Training with the people whose hands will be on it, in your systems, doing your work. Short recorded clips, one per task, because nobody ever rewatches a forty-five minute walkthrough. Written documentation you can edit yourself. Every account in your name on your billing. Every piece of access we were given, handed back and switched off.
What we needRotate the passwords we were given. We will remind you.
30 days after go-live
The thirty-day review
A month is how long it takes for the novelty to wear off and the awkward cases to turn up. We look at what gets used, what broke, and whether the hours we predicted were real — including the places we were wrong. If nothing more is needed, that is a perfectly good place to stop.
Four things we will need.
None of them are onerous and all of them are load-bearing. A project that runs late almost always ran late here, not in the building.
One person who can decide
Reachable inside a couple of working days. Builds stall far less often on hard problems than they do waiting for somebody to choose between two options.
Your content, by its date
Copy, photographs, documents, team details. This is the single most common reason a project runs late, so we say it on day one instead of diplomatically in week five.
An hour of the person who does the work
For demos, and for the session before go-live. Their time is the most valuable input the project gets, and the easiest one to under-book.
A heads-up on anything in flight
An office move, a software migration, a partner retiring, a busy season. None of that is a problem. Learning about it in week three is.
How we ask for the keys, and how you get them back.
At some point we have to get inside the systems your business runs on. If you hold privileged or clinical material, how a supplier asks for that access deserves more of your attention than anything else on this website. So here is our answer before you have to ask the question.
We will never ask you to email us a password
Not a password, not an API key, not a recovery code. Mailboxes get backed up, forwarded, and — in your line of work — discovered. If a secret genuinely has to move it travels through a one-time link that expires, and you change it at handover regardless.
We ask to be invited, not to be given your login
You add us as users on systems you already control, with the narrowest permissions that do the job. Never a shared account. Never yours.
You can switch us off at any time
Without asking, without notice, and without breaking anything you have paid for. We keep a written register of every access we hold, and hand you that same list at the end with every line struck through.
Your data does not go into a chatbot
Not into a consumer AI tool, and not as an example in somebody’s prompt. If any part of a build would send your data to a third-party AI service, you are told which service and asked in writing first. You can say no and still have the build.
It still starts with a conversation, and the conversation is free.
None of it applies until you have had the call, read the map, and decided there is something here worth building. Plenty of people read the map and stop.