PROCESS

Written down first. Shipped every week.

Every build runs the same six stages, from discovery to handover, with one lead who owns it and a working demo you see every week. This is the whole process, including where AI does the work.

Start a project

The phases

Six stages, in order

Nothing gets built until the specification is precise. After that, you see progress every week.

  1. Discovery

    Goals, users and constraints mapped in the first week. We interview the people who will use the product and the people who will own it. No code is written until everyone is aligned on what is being built and why.

    Where AI does the work: Research

    Deep research in hours. Competitive scans, user interviews, and market reports. Synthesized by AI, acted on by our team.

  2. Requirements

    The written specification is the product at this stage. Every screen, rule and integration in plain language, with the open questions answered before they become rework. You sign it off. When it is precise, the build is fast; when it is vague, nothing downstream can fix it.

    Where AI does the work: Design

    Mockups, wireframes, user journeys, and flows. Generated fast, refined fast. No throwaway prototypes.

  3. Build

    Sprints with a demo every week, including the messy parts. Every pull request is reviewed twice, once by our tooling and once by an engineer. Scope is renegotiated against the outcome, in writing, not against the original document.

    Where AI does the work: Code

    AI pairs with every engineer on our team. We move faster, ship more, and spend human effort where it counts.

  4. Quality

    A dedicated QA lead and team test every release against the specification you signed. Nothing reaches a client release without going through them. Bugs found here are cheaper than bugs found by your users.

    Where AI does the work: Review

    Every pull request gets reviewed twice. Once by AI, once by our engineers. Bugs and risks rarely slip through.

  5. Launch

    Infrastructure as code, pipelines that deploy on their own, monitoring in place before the first user arrives. Launch day is a checklist we have run before, not an event.

    Where AI does the work: DevOps

    Infrastructure as code. Pipelines that run themselves. AI watching production around the clock.

  6. Support

    We stay on after launch: monitoring, fixes, iteration, and a team that already knows the codebase. If something breaks six months later we want to know about it, and we are the ones who fix it.

    Where AI does the work: Support

    Bugs caught before users find them. In-product copilots that actually help. Issues resolved fast, not escalated endlessly.

How we estimate

Six streams on every estimate

An estimate that cannot explain its own numbers gets challenged, so ours is written by stream and the assumptions sit next to the figures.

  • Requirements

    Discovery, the written specification, and the answers to every open question. The largest stream on most projects now, because it is where the product is decided.

  • Backend

    APIs, data models, integrations and the rules that make the product behave. Estimated per module against the specification, not per developer.

  • Frontend

    Every screen a user or an operator touches, web and mobile, estimated per screen from the signed specification.

  • Quality assurance

    Test plans written from the specification, executed on every release, with regression on every fix.

  • DevOps

    Environments, pipelines, monitoring and the launch itself. Set up early so the first demo already runs somewhere real.

  • Delivery management

    One named lead who runs the sprints, the approvals, UAT and the client channel, from kickoff to handover.

Effort and calendar are estimated separately. Four days of integration work can sit behind six weeks of waiting for a third-party credential, and the estimate says which is which.

What you see

Every week, the same three things

A demo

Working software, shown to you, not a status report about you. What shipped, what did not, and what is next.

A written log

The decisions made that week and why, so nobody has to remember a call from three sprints ago.

The same lead

One person who owns the engagement end to end and is reachable between the demos.

The people behind the demos are on the team page.

At the end

What you walk away with

  • The code and the IP, assigned to you in every contract from the moment it is written.
  • A documented codebase and a documented roadmap, written for the engineer who inherits it two years from now.
  • Environments and pipelines your own team can run without us.
  • A support arrangement if you want one, scoped separately, with the people who built it.