How it works

How a sprint runs, from the first call to the demo.

You buy a sprint, not a month: a fixed scope, a fixed price, and engineers assigned to it for its whole length. Here is each step, including the parts most agencies keep vague: when you pay, where you hear from us, and what happens when your plans change.

› STEP BY STEP

One sprint, in order.

  1. 0130 MINUTES

    The scoping call

    You talk to the engineer who would lead the sprint, not a salesperson. The price is already on the site, so the half hour goes on your code or your spec.

    1. 0–5 minWhat you are building, and what has been stuck.
    2. 5–20 minWe read the code or the spec together and find the real blocker.
    3. 20–27 minWe agree the first sprint: scope, length, and price.
    4. 27–30 minAccess, repositories, and a start date. Usually the same week.

    Not ready yet? Book anyway. Half these calls end with a plan and no sprint, which is a fine outcome for both of us.

  2. 02BEFORE THE SPRINT STARTS

    Scope and payment

    What the sprint delivers is written down before it starts, along with its length and its price. Sprint fees are paid in advance, and any add-ons go on the same invoice at their flat per-sprint price.

    That invoice is the whole bill. There is no hourly billing, no overtime, and no charge for time spent scoping, talking or reviewing. Hosting, model usage and paid libraries are billed to your own accounts, never marked up through us.

    Change your mind before the sprint starts and the whole fee comes back.

  3. 03MEDIAN 4 DAYS FROM THE CALL

    Access and the first commit

    We work in your repositories, your framework and your review process, not a parallel codebase handed over at the end. Median time from the scoping call to the first commit is four days.

    WHAT WE NEED FROM YOU
    • Access to the systems the sprint depends on, when it starts.
    • One person who can make decisions and answer questions within a working day.
  4. 04EVERY WORKING DAY

    During the sprint

    Every working day you get a written update: what shipped, what is next, and what needs your call. It arrives in the tools you already run, whether that is Slack, Teams, Linear or Jira, so there is no new app to join.

    Our day overlaps London’s by five hours and New York’s by three. The written update covers the rest, so nobody waits on a timezone to know where things stand.

    Work arrives as pull requests and merges behind your review process. New requests go in the queue for the next sprint instead of displacing committed work. If access or a decision holds things up, the sprint pauses rather than burns, and restarts when you are ready at no extra cost, though its dates move.

    DAILY UPDATE · DAY 3EXAMPLE
    SHIPPEDSaved addresses at checkout, merged in PR #41
    NEXTUK postcode validation, in review tomorrow
    NEEDS YOUWhich shipping zones launch first, by Thursday
    Three lines, every working day, wherever your team already talks.
  5. 05THE LAST DAY

    The demo

    The sprint ends on a call where we show you what shipped, working, in your product. Then it is your decision: run the next sprint, or stop.

    Stopping needs no notice and carries no penalty, and nothing further is billed. The IP has been yours since the first commit, and on request we hand over documentation, access and anything outstanding within five working days.

◈ THE FIRST 14 DAYS
First 14 days are on us. Not convinced? Full refund, regardless of sprint length. It runs from the day your first sprint starts, and covers every sprint fee and add-on paid in that window. Refund policy ›
› QUESTIONS

Asked about how sprints run

The current sprint stays as agreed, which is what makes a fixed price possible. Anything new goes to the top of the queue for the next sprint, and sprints are one or two weeks, so nothing waits long.

The first step is a 30-minute call.

With the engineer who would lead the sprint. You leave with a scope and a price, and the first 14 days are on us.

◈ 14-DAY GUARANTEEIP YOURS FROM DAY 1NO LONG CONTRACTS