Why we charge by sprint, not by hour
Hourly billing rewards slow people. Per-project billing rewards over-promising. Two-week sprints reward the only thing that matters: shipping something.
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.