How delivery works
Discover → Confirm scope → Implement → Validate → Handover
The same five-stage method runs every engagement, from the £395 Readiness Audit to the £6,500 Enterprise Pilot. Scope is fixed in writing before work begins, validation runs against named real clients, and handover leaves your team able to operate the result without us.
Your delivery schedule is confirmed during intake.
The method
Five stages, in order, every time
Each stage has a defined purpose and a defined output. Nothing moves to the next stage on assumption — scope moves to implementation only once it is confirmed in writing, and implementation moves to handover only once validation results are recorded.
Stage 1 of 5: Discover
Understand the implementation, constraints and intended clients.
- Intake form collects the technical facts: implementation language, hosting, transport, authentication, target clients and repository availability.
- We review the inputs before any commitment and raise anything that looks out of scope immediately.
- For enterprise engagements, discovery includes sessions with your platform, security and identity owners.
Stage 2 of 5: Confirm scope
Fixed scope, named clients and acceptance criteria — in writing.
- The written scope names the implementation covered, the real clients and test conditions used for verification, the deliverables, the exclusions and the acceptance criteria.
- Anything discovered later goes through written change control: assessed, priced and agreed before work proceeds.
- Delivery start is confirmed after intake and scope validation. If we decline before commencement, payments are refunded in full.
Stage 3 of 5: Implement
Work happens in your repository and environments, under your control.
- Code changes arrive as reviewable pull requests on branches — never direct pushes to your default branch.
- Credentials are customer-controlled and least-privilege; production access only where the written scope requires and authorises it.
- You see progress as it happens, not at a final reveal.
Stage 4 of 5: Validate
Verification against the named clients and conditions agreed in scope.
- Automated tests cover changed behaviour and run in your CI.
- The named real clients from the written scope are exercised against the agreed test conditions, and the results are recorded — pass or fail.
- Where implementation is in scope, deployment and rollback plans are documented; for the enterprise pilot the rollback is exercised at least once in a non-production environment. The audit assesses deployment and rollback posture rather than producing those plans.
Stage 5 of 5: Handover
Your team can run, extend and evidence the result without us.
- The Production Evidence Pack is assembled and walked through with your team.
- Access granted for the engagement is removed, and removal is confirmed to you.
- You know what was done, why, how it was verified, and what to do next.
Scope control
Fixed scope means fixed in writing — not fixed in goodwill
Fixed-price work only stays fair if scope is controlled honestly on both sides. These are the five controls that hold on every engagement, and they are written down before delivery starts.
- Written scope
- Before delivery starts you receive a written scope covering the implementation included, the deliverables, the exclusions, the timetable and the acceptance criteria. If something is not in the document, it is not assumed.
- Named clients and test conditions
- “Works with MCP” is not a test condition. The written scope names the real clients your engagement is verified against — versions where relevant — and the conditions each must complete. Results are recorded, pass or fail.
- Written change control
- Anything discovered after scope confirmation goes through written change control: it is assessed, priced and agreed before any work proceeds. Scope does not grow silently, and neither does the amount you owe.
- Acceptance criteria
- Every service publishes its acceptance criteria before purchase, and the written scope makes them specific to your engagement. Where a service carries an acceptance milestone, that balance falls due only against those agreed criteria — not against a delivery claim.
- Refund before commencement
- Intake sometimes shows an implementation is not a fit for a fixed-price engagement. When that happens we say so before starting: if EcoCitizenz Ltd declines an engagement before commencement, payments already made are refunded in full.
Each service page states its own scope, exclusions and acceptance criteria in full. See the four services
Who delivers
One accountable party, disclosed specialists
In plain language: your contract is with EcoCitizenz Ltd, responsibility for every agreed deliverable stays with us, and nobody gains access to your systems without you knowing who they are and on what terms.
The disclosure, as it appears in the engagement terms
EcoCitizenz may use appropriately vetted specialists or subcontractors to support delivery. EcoCitizenz remains responsible for the agreed deliverables. Any specialist access to customer systems or confidential information will be disclosed and governed by the engagement terms.
How access is granted, scoped, logged and removed is described in full in the security and access model.
The method is fixed. The next step is yours.
Pick the fixed-scope service that matches where you are, or start free by scanning an MCP configuration in your browser.
Your delivery schedule is confirmed during intake.