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.
One sprint, in order.
- 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.
- 0–5 minWhat you are building, and what has been stuck.
- 5–20 minWe read the code or the spec together and find the real blocker.
- 20–27 minWe agree the first sprint: scope, length, and price.
- 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.
- 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.
- 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.
- 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 3EXAMPLESHIPPEDSaved addresses at checkout, merged in PR #41NEXTUK postcode validation, in review tomorrowNEEDS YOUWhich shipping zones launch first, by ThursdayThree lines, every working day, wherever your team already talks. - 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.
Asked about how sprints run
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.