Know what it costs, before you commit.

You have something to build and three figures in front of you that you cannot compare. The first step is not choosing a supplier: it is understanding what you are buying.

What really happens

What you get

A plan you can take anywhere

Whether it is an MVP or a complete product: functional and business requirements, proper feasibility checks, and issues that emerge before the project is halfway through. Timelines based on team size, and what it will cost to maintain and evolve afterwards.

What it asks of you

Time from the people who know the problem

It takes a few sessions with the people who know what the product needs to do and why. You do not need to know how it is done: that is our job.

What it is not

It is not a disguised quote

The document has value even if you work with someone else afterwards; it is precisely what lets you obtain comparable proposals. If you use it to go elsewhere, it has worked all the same.

Starters

The doors.

Build, Scale and Rescue are long commitments, and before taking them on it is normal to want a clear view.

Starters are a way to begin without committing: they take a few weeks, cost little, and end with something in hand that is useful even if you work with someone else afterwards. Three give you an answer before you start: a plan, a check, an audit. The fourth, the Dry Run, shows you how we work on a real piece of your project.

How we work from there

  1. Before

    You decide where capacity is spent

    Every activity is described, designed from a technical and interface point of view, estimated in terms of effort, then waits until you approve it. That way you see what will be built before time is spent building it. You are not approving an invoice: you are deciding where the time you have already bought goes.

  2. Every day

    You see the pipeline as it moves

    You have access to the tool where the work lives: its status, which two-week sprint it belongs to, whether it is ahead or behind. Not an end-of-month summary — the same view we use.

  3. During

    No one releases their own code

    The person who writes is not the person who approves. Every change passes through a second engineer before it goes anywhere.

  4. Before release

    An environment where you can test it

    The work arrives somewhere you can see it before production. If it is not what you expected, it goes back.

  5. Always

    The code and servers remain yours

    No technical constraint that forces you to stay.

The method, in detail