How it works.
You buy a result, one week at a time: a working version of your app, tested, in accounts your company owns, built on the version before. This page is everything that goes into it, and how you can check it without us in the room.
The week, day by day
Invoiced the week before.
- Monday to ThursdayAround the clockThe fleet builds and tests. In week one, your app moves off the tool's hosting into your own accounts, and something is running by Friday.
- Thursday24 hours before the callA short recording of the week's work. Nothing to write up: the app is the brief.
- FridayOne hourOn a call. You decide what goes into the next week, or that there isn't one.
Direction, not requirements
You say what you're thinking. We don't ask how the software should work, because you don't know yet, and asking forces the decision early. The fleet builds something that embodies the idea and you react to working software. The building is the requirements process. Features that felt critical turn out to be later work, and things nobody could articulate turn out to be first.
Finding the one shape
Under a hundred job boards, or a set of property CRMs, or every assistant's private habits, there is one shape. Finding it is the architecture, and it is the part an agent can't do. Agents fill a shape in; they don't find it. This is the step that decides whether the rest works, and it is why the tool you used could add features but never remove the mess: nobody was finding the shape.
Who builds and who checks
Our agents write the code, around the clock, on your project only, under instructions written for it. Nobody reviews the agents while they write. Given room, an agent invents work that doesn't need doing, so the fleet runs and whatever comes back wrong is binned. The review is at the output, not the keystroke: a senior engineer reads what survives, runs it on a clean machine, and tries to break it before you see it. Tests run on every change and are written to catch what the next edit would break, not the last one. If a test fails, the week is not done, and you pay nothing extra.
What it is rebuilt into
Docker on commodity servers behind nginx, PostgreSQL for the data, and conventional frameworks, in accounts your company owns. Nothing exotic, on purpose: conventional enough that the next person can read it, and so that your own tools can extend it after handover. Week one usually includes moving the app off the tool's hosting.
Keeping it safe
Backups we have restored once to prove they work. Passwords and keys kept out of the code. The parts we didn't write kept up to date. Access only for the people who need it. What the accounts will bill you each month after we are gone is in the assessment, before you pay for a week.
Four commitments, so the work can be checked without us
These are written into the contract before work starts. None of them is a feature.
- Custody from the first commit.The repository lives in a GitHub or GitLab organisation in your company's name, and the cloud accounts are opened in your name. The owner field on day one is the proof, and someone you didn't hire can verify it from a printout in under a minute.
- Documentation as a named deliverable, with three tests.It is read by someone who didn't write it, it runs on a fresh machine from a freshly provisioned account, and it is signed off against the agreed scope. If any test fails the work isn't done, at no extra charge and inside the same week. For a codebase a fleet wrote, the fresh-machine test is the one that matters most, so it is run first.
- A rehearsed handover, in the first week.Someone who didn't write the system runs it through those three tests in week one. A tested handover is evidence; an untested one is a claim.
- Decision records, written as the calls are made.Every architecture decision, dated, with the reasoning and the alternative that lost, delivered with the work. This is how you check that a human made the decisions and not the fleet.
How many weeks
Before you pay for one, you have an estimate in writing: a number of weeks, and the two or three things that would change it. After week one, we confirm it or revise it once, in writing. We do not sell a fixed total, because nobody can price the whole job before the first week and be honest about it. One client had a beta in a month and kept buying weeks for ten months.
The bill
€4,900 a week, in euros, invoiced before the week starts. About $5,700 at September 2026 rates. Building, testing, hosting and keeping it safe are all in it. There is no invoice in month three with extras on it. Price and terms are on one page.
Stopping
Say so on the Friday call. No notice, no fee, no minimum. What you have that day works, and it keeps running in your account, because it was never in ours.
Who needs to be there
Someone on your side who knows the business, for one hour a week. It can be you. Nobody technical. We work on CET, which overlaps a UK or European working day fully and a US morning in your afternoon.
Don't send it if any of these is true
- You could fix it yourself, given a clear week.Take the week; we cost more than it does.
- You want one fixed price against a frozen spec.We give a number of weeks in writing before you pay for one, and revise it once after week one. We don't sell a fixed total.
- Nobody on your side knows the business it is for.We can build it. We cannot know what it should do.
- What you want fits in one prompt.Go and finish it in the tool.
- You need a developer who is still inside your company in three years.Hire one. We would say so anyway.
- You have developers and need someone to manage them.This stands in for a team; it does not run one.
- The money isn't there yet.Keep the link. We will still be here.
If you are an agency: send us the one you can't take. You stay on the calls, the client stays yours, and the look at their code is free.