Why we charge by sprint, not by hour

Three pricing models. One outcome that matters. Let's look at the incentives.

Hourly

Hourly billing pays you to spend hours. Every hour is revenue. The slow developer earns the same per hour as the fast one — and over a project, the slow one earns more. Worse, the client pays for thinking time, debugging time, learning time, meeting time. Most of which they shouldn't be subsidising.

Fixed-bid

Per-project pricing reverses the problem: now the studio wants to deliver as fast as possible, even if quality suffers. The first thing to go is testing. The second thing is documentation. The third thing is the parts the client didn't explicitly ask for but absolutely needed.

Both models put the client and the studio on opposite sides of the table.

Sprint

We sell two-week sprints at a fixed senior-team rate. Every sprint, the client gets: an agreed scope going in, a shipped deliverable coming out, and a written retro that lists what we want to do next sprint and what we'd cut.

At the end of every sprint, the client can stop. Walk away. Take what we built, the code, the brand, the deliverables. We don't lock anything down.

Why this works

Two reasons. First, the client sees velocity weekly. They know what they're paying for. Second, our incentive is to ship cleanly enough that next sprint goes faster — not to drag work out for revenue.

The model also forces us to scope ruthlessly. A two-week sprint can't hide a six-week build. We say no to scope creep at the planning meeting, not at the deadline.

The honest part

This isn't right for everyone. Clients who want a fixed price for a fully-specced thing — we send them to a fixed-bid agency. Clients who want hourly contract developers — same. We work with founders who want to ship something every two weeks and trust the process. Different shape.

FAQ

How does sprint pricing actually work?

We sell two-week sprints at a fixed senior-team rate. Each sprint takes an agreed scope in and produces a shipped deliverable, plus a written retro covering what comes next and what we'd cut.

Why is charging by sprint better than charging by the hour?

Hourly billing pays the studio to spend hours, so slow development earns more and the client pays for thinking, debugging, learning, and meeting time. A fixed sprint rate removes that incentive, since our goal becomes shipping cleanly so the next sprint goes faster.

What's wrong with a fixed-bid contract?

Fixed-bid pushes the studio to deliver fast even if quality suffers, so the first things cut are testing, then docs, then the parts the client needed but didn't explicitly ask for. Like hourly, it puts the client and studio on opposite sides.

Am I locked in if I want to stop?

No. At the end of every sprint you can stop and walk away with the code, brand, and deliverables, with nothing locked down.

Is sprint pricing right for everyone?

No. Clients who want a fixed price for a fully-specced thing are better served by a fixed-bid agency, and those wanting hourly contract developers should go elsewhere. We work with founders who ship something every two weeks and trust the process.