Skip to content
How we work

Most project failures are not technical. They are scope, communication and finding out too late. This sequence exists to remove all three.
How we work

Six phases.
No surprises.

The same sequence on every project, so you always know what is happening now and what comes next.

  1. 01

    Discovery

    3 – 5 days

    We work out what actually needs building, and what does not.

    A short, intense phase of questions. Who is this for, what breaks today, what does success look like in numbers? We interview the people who will use it and read the code you already have. The output is a written scope with the things we recommend cutting called out explicitly.

    • Written scope document
    • Technical assessment
    • Fixed estimate & timeline
  2. 02

    Architecture

    1 week

    Decisions get made on paper before they get expensive in code.

    Data model, system boundaries, third-party choices, hosting, and the tradeoffs behind each. You get a document you can hand to any engineer for a second opinion. This is the cheapest possible point to change your mind, so we make it easy to.

    • Architecture document
    • Data model
    • Stack decisions with rationale
  3. 03

    Design

    1 – 3 weeks

    Interface design in the browser, not just in Figma.

    We design the core flows properly, then build a real component library in code. Designing in the medium it ships in means no handover gap and no "that is not what the mockup showed" — you click through the actual thing early.

    • Core flow designs
    • Coded component library
    • Interactive prototype
  4. 04

    Build

    3 – 16 weeks

    Weekly working software, not weekly status updates.

    One-week cycles, each ending in something deployed you can use. You have access to the repository, the board and us throughout. Nothing is saved for a big reveal, because big reveals are where projects go wrong quietly for two months.

    • Weekly deploys
    • Preview environment
    • Open board & repository access
  5. 05

    Launch

    1 week

    The unglamorous checklist that decides whether launch day is calm.

    Load testing, error monitoring, analytics, backups, rollback plan, SEO and accessibility audits, and a rehearsed deployment. We go live with you watching the dashboards, not on a Friday afternoon.

    • Launch checklist signed off
    • Monitoring & alerting live
    • Rollback plan
  6. 06

    Aftercare

    Ongoing

    We stay on for the month where the real bugs surface.

    Thirty days of included support after launch, because the issues that matter appear under real usage, not in QA. After that you can take it fully in-house with a documented handover, or keep us on a retainer.

    • 30 days included support
    • Handover documentation
    • Optional retainer
Principles

What we hold to.

These are not posters on a wall. Each one shows up as a concrete behaviour in how a project runs.

  • We tell you what to cut

    Most projects fail from scope, not from code. The most valuable thing we do in week one is talk you out of features you do not need yet.

  • You own everything

    Your repository, your accounts, your infrastructure, from the first commit. No proprietary lock-in, no hostage situation at renewal time.

  • Fast is a feature

    Performance budgets are agreed before we start and enforced in CI. A slow product is a broken product that happens to render.

  • Small team, senior only

    No layers, no account managers, no junior developers learning on your budget. You talk directly to the people writing the code.

  • Accessible by default

    WCAG 2.2 AA is the baseline, not an upsell. Keyboard navigation, screen readers and reduced motion are handled as we build.

  • Honest about AI

    We build AI features where they remove real work, and we will tell you plainly when a database query would do the job better.

Questions

Common questions.

  • With a thirty-minute call, no charge and no deck. If it looks like a fit we run a short paid discovery, which ends in a written scope and a fixed estimate. You can take that document elsewhere if you would rather — it is yours.