The review, on one page.
Software delivered in versions, each one scoped and priced before it starts, each one graded against a standard you can apply without asking us anything. We're not an agency and not a freelancer. You get a senior engineer in your Slack with an agentic team behind him, working in your GitHub. The software is yours as it lands — we don't take your product away.
- No minimum term. Either side may end an engagement at the end of any version, on written notice. No exit fee.
- The master agreement is sent on request, before any signature. Governing law is England and Wales. Payment terms are 14 days.
- Security is a fixed module, not a phase that varies by project. What it produces and what you keep is on the security page.
Start with the landing zone
A team has work that outgrew its laptops. We build the place the work runs, then take apps into it one at a time. It is a fixed scope rather than a project that grows, and the scope is these six things.
- 1A cloud environment. Yours, in your own account.
- 2Shared storage. One place the team's data lives.
- 3On-demand compute. Runs that took a laptop a day, run when asked.
- 4Team and user access separation. The boundary every app that moves in inherits.
- 5An API. How the team's own tools reach it.
- 6A deploy path for the team's own tools. So they ship without us.
All six, every time
The six are fixed: not a menu to pick from, and not a starting point to add to. A landing zone that ships four of them is a bespoke project wearing the name. Dropping one, or adding a seventh, needs a written reason and sign-off.
Week one is a written deliverable
For each of the six: what is reused from the last landing zone, what has to be built fresh, and a written reason for every fresh build. That record is what the next one starts from.
The place, not the apps
The landing zone is where the work runs. Moving an app into it is desk work or a version, and is never inside the platform price. Then the desk runs: apps move in one at a time, metered by the day.
Who has bought this
A research team, 15 scientists. Arrived: a run took a day or two, on one laptop. Left: a shared cloud pipeline the whole company uses, with the desk taking their tools in since.
We publish no typical duration for this shape. One has been delivered and its ongoing form is running, but we have not measured a repeatable number, so we do not quote one.
How the work is bought
A version is the unit. A piece of work with a scope and a fixed price, agreed before it starts. A version takes a week by default; one that runs longer costs no more. Build weeks are invoiced weekly — the week is the invoicing rhythm, not the unit charged.
Build versions
Scoped and priced before it starts. One that runs longer costs no more.
Slack desk
Questions and small requests, including taking an app into the landing zone.
Maintenance
Once live: monitoring, updates, patches, a monthly check on the core.
There is no hourly rate
Larger shapes — a platform for a team, or us as your engineering side month to month — are priced for your scope in a statement of work. Scope is set one version at a time, and either side may end an engagement at the end of any version, on written notice. There is no minimum term and no exit fee. Work already delivered is already in your repository and stays yours.
Asking for a pilot?
A pilot is one version: €4,900, scoped before it starts, and you stop at the end of it if it isn't what you wanted. There is no separate pilot product and no separate pilot price — the cheapest way in is the same way everyone else comes in.
How a version is graded
Every version is graded against twelve elements, and you see the grade — including anything that was missed. The agreement's own delivery standard is its §5; these twelve are how we grade against it, and what you are left holding as evidence.
- Deployment and environments
- Automated checks on every change
- Sign-in and roles
- Customers kept apart
- One core, one contained piece per outside service
- Secrets out of the code
- Backups, with a restore performed
- Logging and monitoring
- Tests
- Written security specification
- Handover notes and a recorded walkthrough
- Open-source licence check
The acceptance test
Your own engineer asks your own AI tool for a feature we never worked on: the tests stay green, it deploys, and nothing else breaks. It is yours to run after handover, and it is recorded as run, rehearsed, or not run with the reason.
Security. Where a statement of work includes the security week, the product is checked against a written security specification and the report is yours to keep. Every component is graded for its licence and the inventory is handed over with the version.
What the security week producesOwnership, IP and data
Yours as it is created
Rights in the deliverables assign to you as and when they are created — not at a handover, not at go-live, and not on final payment. All work lands as pull requests in your repository, on your infrastructure. If an engagement stops mid-version, what has been delivered is already yours.
What we keep
Our own tooling, prompts, agent configurations, templates and generic, non-client-specific patterns stay ours and we reuse them for other clients. Your product, your code and your data are not in that set.
Personal data
Where we process personal data on your behalf, we tell you which sub-processors and AI providers are used on your work, we give notice before adding a new one and you may object, and we return or delete personal data at the end of the engagement. If your engagement touches personal data, tell us early.
If something breaks, who is responsible?
Your company is responsible for the software it owns and runs, exactly as it would be if it had been built by an agency you hired or by engineers on your own payroll. We are responsible for doing the work to the delivery standard, with reasonable skill and care — and for fixing it at our cost if it does not.
§11 of the master agreement is the operative version. It carries the fix-or-refund remedy, what each side's liability is capped at and what the cap does not reach, the losses neither side is liable for, and an indemnity from you for third-party claims arising out of your product, your data and your regulatory position.
For your review. The master agreement is sent on request before any signature. Governing law is England and Wales. Payment terms are 14 days. What we do not yet have — no insurance policy, no IP indemnity, no data-processing agreement drafted — is written out on the security page rather than left for you to discover in the document.
Send us what you have. Our take back within two days.
A link, a repo, architecture notes, or a few lines on the one thing that has to change. Back in writing: what it needs, in what order, the milestones, one week or more, and a price.