A process built for people who hate surprises

Engagement steps

1. 01

   Discovery call

   A 30-minute conversation about your goals, product and constraints. We ask questions, you get an honest first read on feasibility, approach and rough effort — free of charge and free of pressure.

   You provide

   A description of the product and the problem, plus whatever already exists — a brief, designs, a staging URL, an existing test suite, a previous audit. Partial is fine; most of this call is us asking what is missing.

   You get

   • A written summary of what we understood, so a misunderstanding surfaces now rather than in week three.

   • An honest read on feasibility, including the parts we think are harder than they look.

   • A recommendation on which discipline actually fits — sometimes that is fewer services than you asked about.

   • A rough effort band, clearly labelled as rough.

2. 02

   Scope & proposal

   We turn the discovery into a written proposal: scope, deliverables, timeline, price and assumptions. You know exactly what you are buying before any work begins.

   You provide

   Answers to the open questions from discovery, and your decisions on priority where the full scope does not fit the budget or the deadline.

   You get

   • A written proposal with deliverables, the first review date, launch milestones and price.

   • An explicit out-of-scope list — the part most proposals leave out, and the part most disputes come from.

   • The assumptions the estimate depends on, so it is obvious what changes the number.

   • A recommended sequence if the work is better split into phases.

   • The included launch checks, any additional QA or security scope, external running costs and the duration of post-delivery support.

3. 03

   Kickoff & planning

   Access, environments, communication channels and a shared plan. We agree how progress is demonstrated — usually a weekly demo or written status you can forward internally.

   You provide

   Access to environments, repositories and any accounts the work needs, plus one named contact who can make decisions without convening a committee.

   You get

   • A shared plan with the sequence of work and the checkpoints on it.

   • An agreed demo or status cadence, and the channel it runs in — yours, not ours.

   • A written definition of done for the engagement, so acceptance is not a matter of opinion later.

   • Confirmation that our access works, before the clock starts.

   • An agreement on AI tooling, permitted inputs and human review responsibilities when AI assistance is in scope.

   • For an AI pilot: a task baseline, approved evaluation examples, stop conditions and the people who will review and operate it.

4. 04

   Delivery in iterations

   Design, development, testing or assessment work proceeds in short, reviewable increments. You see real progress continuously — never a black box that opens at the deadline.

   You provide

   Feedback on each increment, and a decision when a question blocks progress. The faster that loop runs, the less rework the engagement carries.

   You get

   • Reviewable increments — running code, executed test runs, findings as they are confirmed.

   • A weekly demo or written status update you can forward internally without editing it first.

   • Immediate written notice when something threatens scope, budget or timeline — with options, not just the problem.

   • A visible record of what changed and why, so the history survives staff turnover on either side.

   • Checks matched to each change: focused tests, review of generated code and performance measurements where behaviour or page speed is affected.

5. 05

   Review & handover

   Final review against the agreed scope, complete documentation, and handover of every artifact — code, test suites, reports — into your ownership.

   You provide

   An acceptance review against the definition of done agreed at kickoff, and the destination for the handover — your repository, your issue tracker, your accounts.

   You get

   • Every artifact the engagement produced: source, test suites, reports, configuration.

   • Documentation written for whoever inherits it, not for whoever wrote it.

   • Acceptance evidence showing the important journeys tested, known limitations and any follow-up risks you have agreed to carry.

   • A walkthrough session, recorded if your team is distributed across time zones.

   • Transfer of any credentials or infrastructure created for the project, and deletion of our copies.

6. 06

   Support & iteration

   A defined post-delivery support window is included in every project. After that: retainer, ad-hoc support or a clean goodbye — your call, no lock-in.

   You provide

   Anything you find after handover. Reports during the support window are exactly what the window is for — you are not imposing.

   You get

   • Fixes for defects in delivered work within the support duration and coverage written into the proposal.

   • A written record of anything changed after handover, so your documentation does not silently drift.

   • An honest answer on whether a follow-on engagement is worth it — including when we think it is not.

   • A clean exit if you want one: no proprietary tooling, no lock-in, nothing that needs us to keep running.