For the first five years of the studio, we billed hourly. Track time, send invoices, reconcile at the end of the month. It worked — technically. But it created a dynamic we didn't like: every conversation about scope was also a conversation about money. The client would ask "can you also fix this?" and pause, calculating whether the question was worth the billable time. We'd answer honestly but feel the friction. The meter was always running, and everyone knew it.
In 2023 we switched to a model we call the sprint contract. Fixed scope, fixed price, two-week cycles, with an exit ramp after every sprint. It changed everything about how we work with clients, and we're writing it out here so prospective clients know exactly what they're signing up for.
§ 01Why we stopped billing hourly
Hourly billing has three problems that compound over time:
It penalizes efficiency. If we solve a problem in two hours instead of ten, we earn less. The incentive structure rewards slow work, and while we never padded hours deliberately, the system's incentive is fundamentally misaligned with the client's interest.
It creates anxiety about communication. Clients hesitate to send messages, ask questions, or request small changes because every interaction costs money. The best client relationships we've had were the ones where communication was free-flowing. Hourly billing chokes that flow.
It makes cost unpredictable. The client gets an estimate at the start and a surprise at the end. Even with good tracking and regular updates, the final number is never exactly what was estimated. That unpredictability erodes trust, even when the overrun is justified.
The best client relationships are the ones where asking a question doesn't start a billing clock.
§ 02How a sprint works
A sprint is two calendar weeks — ten business days. Here's the rhythm:
Day 1 (Monday): Sprint planning. A 60-minute call where we review the backlog, agree on the sprint's deliverables, and write them down in a shared document. Every deliverable is phrased as a user-visible outcome: "Checkout flow handles multi-currency," not "Implement currency conversion logic." By the end of the call, the client knows exactly what they'll have on Day 10.
Days 2-9: Build. We work. The client gets access to a staging environment that updates continuously. We post daily async updates in Slack — what shipped, what's in progress, what's blocked. If something is blocked on the client (an API key, a design decision, content), we flag it immediately. Blocks don't wait for the next standup.
Day 10 (Friday): Sprint review. A 45-minute call where we demo everything that shipped, review anything that didn't, and discuss the next sprint. The client sees working software, not slides. If they want to continue, we plan the next sprint. If they don't, we hand over the code and documentation. No hard feelings, no penalties, no exit fees.
If the client wants to stop, they stop. No penalties, no exit fees.
— Sprint contract, Section 4
§ 03What's included
Every sprint includes:
- Design and engineering. We're a full-stack studio. Sprints include UI design, frontend, backend, and infrastructure work as needed. We don't split these into separate line items.
- Code review and QA. Every feature is reviewed by a second engineer before it ships. We test on real devices, not just Chrome on a MacBook.
- Deployment. We deploy to staging continuously and to production at the end of each sprint (or more frequently if the client prefers). CI/CD is set up in the first sprint and included in the price.
- Documentation. Every sprint ships with updated technical documentation. When the engagement ends, the client's team can pick up where we left off without a knowledge-transfer phase.
- Communication. Slack access to the team, daily async updates, and as many calls as the client needs. Communication is never a billable extra.
§ 04What's not included
A few things sit outside the sprint scope:
- Hosting costs. The client pays for their own infrastructure (Vercel, AWS, Supabase, etc.). We set it up and manage it during the engagement, but the accounts belong to the client.
- Third-party licenses. Fonts, stock photos, SaaS tool subscriptions — these are the client's expense.
- Scope changes mid-sprint. Once the sprint starts, the scope is locked. If the client has a new urgent priority, it goes into the next sprint. This protects both sides: the client gets predictable delivery, and we get focused build time. Emergency exceptions exist, but they're rare — we've invoked them three times in two years.
§ 05Why clients renew
Our renewal rate is around 90% — meaning nine out of ten clients who complete a sprint sign up for the next one. We've thought about why this is, and we think it comes down to three things:
They see working software every two weeks. Not mockups, not prototypes — deployed, working software that real users can touch. The feedback loop is fast enough that the product improves visibly from sprint to sprint, and the client can feel the momentum.
They can stop anytime. Paradoxically, the ability to leave makes clients more comfortable staying. There's no sunk cost pressure, no contractual inertia. Every renewal is an active choice, which means both sides are in the engagement because it's working, not because the contract says so.
The cost is predictable. The client knows exactly what each sprint costs before it starts. There are no surprise invoices, no scope-creep surcharges, no "we went over estimate" conversations. Budgeting is simple: multiply the sprint cost by the number of sprints in the roadmap.
§ 06When this model doesn't fit
The sprint model works best for product development — building features, shipping improvements, iterating on a live product. It doesn't work well for:
- Pure consulting. If the client needs strategic advice without a build component, a sprint is too structured. We do these as standalone advisory sessions instead.
- Maintenance-only work. If the product is stable and the client just needs someone on call for bug fixes and minor updates, a full sprint is overkill. We offer a lighter retainer for these cases.
- Highly regulated environments. If the approval process for shipping code takes longer than two weeks (common in healthcare and finance), the sprint cadence doesn't align with the deployment cadence. We adapt the model, but it's a conversation.
For everything else — new product development, feature buildouts, migrations, redesigns — two-week sprints with a clean exit after each one have been the best working arrangement we've found. The client gets predictability. We get focus. Both sides get the freedom to walk away if it's not working. That's the whole model.
— End of essay. Want to try a sprint? Start a project →