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 scope, deliverables, timeline 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.

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.

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.

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.

   • 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 agreed support window.

   • 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.