A small team, a fixed scope, and every limit written down.

1. 01

   Fixed scope, agreed in writingbefore day one

   Every engagement names its unit of scope — one workflow, one tool, one system — and the acceptance criteria are written down before work starts. This is what makes a fixed date and a fixed price possible at all; without it, both are guesses dressed as commitments.

2. 02

   A small team, end to endno handoffs

   The people who scope it build it. There is no discovery team handing a document to a delivery team, because that handoff is where fixed-scope engagements go to die and where a third of the budget goes.

3. 03

   Working software weeklynot status reports

   You see it running each week, with your data in it. A four-week engagement cannot afford a reveal at the end — if it is going wrong, the only useful time to find out is week one.

4. 04

   Deployed into your cloudyour tenancy

   The finished system runs in your account, on your bill, under your access controls. We tell clients to own their infrastructure; delivering into ours and calling it ownership would be a contradiction.

5. 05

   Handover as a deliverablerunbooks, not tribal knowledge

   Runbooks, the acceptance record, and a session with whoever will operate it. The test is whether someone who has never met us can run it — which is also the test of whether you actually own it.

The test we hold it to is the handover. You get a repository that reads as though it were written on purpose — conventional structure, tests that describe intent, and comments that explain the decisions rather than narrating the syntax. If the code is only maintainable by whoever generated it, we have shipped a dependency, not an asset.

If we miss the date, you stop paying.

The week after the committed date onward is on us until it ships. The cap: the remedy is free continued work until delivery — not refunds, consequential loss or damages. We cap it there so it is a promise we can keep rather than one that would end us.

You own the code and the IP outright.

On payment, the repository transfers and the IP assigns in full — one clause in the agreement. The boundary: during a post-paid pilot you have full access to the running application under an evaluation licence, not the repository. Source is available for inspection under NDA on request.

No covert protection, ever.

No hidden dependencies, obfuscation, kill switches, time bombs or undisclosed retained ownership. Everything protecting us is a stated contractual term you can read before signing. This is commercial before it is ethical: a single “they booby-trapped the repo” post outlives any deal it saved.

The exit handover is written in from the start.

Own & Operate is monthly and cancellable, and the exit pack is kept current from day one rather than negotiated once you are already unhappy. You hold the code either way, so leaving is a decision rather than an escape.

Your data is never leverage.

Under no circumstances is client data withheld, in any dispute, at any stage. Operational data created while a pilot ran belongs to you and is exported on payment — or on request if you decline the work.

A pilot is not production.

Pilot environments carry no service level and we say so in writing. Why it matters: the honest version of a ten-day post-paid build is one you evaluate, not one you run your business on before anyone has agreed who is on call.

Assessments state their assumptions.

Layer-two and layer-three work is advisory, and recommendations are conditional rather than directive, with confidence stated per finding and the scope of reliance limited in writing. Where we have not walked the path ourselves, the page says so — see the Cloud Exit Assessment.