Introducing Sprint mode

Today we are making Sprint mode the default way to start a Build engagement. A sprint is two weeks, a fixed scope, a fixed price, and a working demo on day ten. You bring a problem. We bring a small team and The Forge. You get production software at the end.

We ran our first engagements this way before we had a name for it. It worked well enough that we have stopped offering anything else to new partners.

How a sprint runs

1. Day 0. A scoping call. We write the sprint brief together: the problem, the definition of done, the number we will measure it against, and what is explicitly out.
2. Days 1 and 2. We stand up the environment, instrument what exists, and ship the first pull request. Nothing waits for a kickoff deck.
3. Days 3 to 8. Build. Daily async updates in your channel, a demo link that updates on every merge, and at most one decision request per day.
4. Day 9. Hardening. Test coverage, load checks, accessibility, and a handover doc drafted by the agent that watched the whole sprint.
5. Day 10. Demo and review. We show what shipped, what we learned, and what we would do next. You decide whether there is a next sprint.

What fits in a sprint

More than most people expect, and less than a rebuild. Good sprint candidates have a clear edge and a number attached. Examples of the shape:

• A customer-facing quoting tool replacing a spreadsheet and a shared inbox.
• A billing migration to a new payment provider with zero downtime.
• An internal dashboard pulling from four sources that previously lived in weekly email.
• A support agent that triages inbound tickets and drafts replies for human approval.
• A marketing site rebuilt on a modern stack, loading in under a second, with the CMS wired in.

Bad candidates are anything with an unknown that could take a week to resolve on its own: a data migration with no schema documentation, an integration with a vendor who has not returned a call. We will tell you if a problem is not a sprint problem, and we will usually suggest a two-day discovery instead.

Why fixed scope and fixed price

Hourly billing rewards slow work. Open-ended scope rewards vague work. A sprint removes both incentives. We agree on what done means before we start, and the price does not move. If we underestimated, that is our problem, not yours. If we finish early, we use the remaining days on the next item in your backlog.

It also makes the decision to work with us small. You are not signing a six-month contract. You are buying two weeks. If the demo on day ten does not earn the next sprint, we did something wrong.

Agents in the loop

Sprint mode is possible because most of the mechanical work is done by agents inside The Forge. They write the first pass of most code, generate and run the tests, review every pull request for the things reviewers miss at five in the afternoon, and produce the handover doc from the actual commit history. Engineers spend the sprint on design decisions, integration edge cases, and the parts of the problem that need a person.

sprint:  partner: regional-field-services   # anonymised  length_days: 10  goal: "Replace spreadsheet quoting with a web tool"  done_when:    - "Reps can create and send a quote in under 3 minutes"    - "Quotes sync to the CRM within 60 seconds"  measure: median_time_to_quote  out_of_scope:    - "Mobile app"    - "Historical quote import"

Get started

Sprint mode is available now for new and existing partners. Pricing is on the pricing page. If you have a problem that fits, describe it at /start and we will come back with a sprint brief within two business days.