Published 2026-08-29 · Jordan Ellis, Founder

Fixed price vs. hourly: why MVP development shouldn't be billed like consulting

Hourly billing isn't a scam. It's the correct pricing model for a real category of work: ongoing engineering support, staff augmentation, maintenance on a codebase that already exists and will keep changing indefinitely. Nobody can fix-quote "keep our systems running for the next year," because nobody knows what that year will contain.

An MVP is a different category of work entirely, and billing it like the first one is where a lot of founders get burned.

The actual difference isn't the work. It's the shape of the work.

Ongoing engineering support has no defined endpoint — more requests arrive as the business changes, forever, by design. An MVP has a defined endpoint: one user, one flow, shipped and live. It's bounded work with a known shape, which is exactly the kind of work a fixed price is supposed to cover. Billing bounded work by the hour doesn't make it more flexible. It just moves the risk of the shape being wrong from the people who defined the shape onto the person paying for it.

Where the risk actually sits

HOURLYFIXED PRICEIf the work runs long,the client's invoicegrows with it.If the work runs long,the shop absorbs it —that's what "fixed" means.RISK: CLIENTRISK: SHOP

That's the whole mechanism. It's not about which model is more honest in principle — plenty of honest shops bill hourly for the right kind of work. It's about which party is better positioned to absorb the risk of a software estimate being wrong, and for bounded, well-scoped work, that should almost never be the founder who's never built software before.

The real argument for hourly — and why it doesn't apply here

The honest case for hourly billing is flexibility: priorities can shift week to week without renegotiating a contract every time. That's a real advantage for ongoing work with no fixed endpoint. It's not an advantage for an MVP, because an MVP's whole point is to not shift week to week — one user, one flow, decided before anyone starts building. If your priorities are shifting that much during what's supposed to be a two-to-four-week build, the problem isn't the pricing model. It's that the scope was never actually fixed, which is a scoping problem, not a billing one.

What to watch for

A shop that insists on hourly billing for a well-scoped MVP, with no willingness to even discuss a fixed number, is telling you something: either they don't trust their own estimation enough to stand behind it, or they'd rather not have to. Neither is a reason to walk away by itself. But it's a reason to ask the question directly, and to notice if the answer is about flexibility instead of about risk.

Not sure where this leaves your own product?

A Forecast engagement turns an unscoped idea into a clickable prototype, a technical plan, and a fixed quote — before you commit to anything bigger.

Start with a Forecast →