Hanad KubatVisit Website →
← Back to blog

Capped Discovery: Founders Choose Fixed Price or Hourly Development

September 19, 2026
Capped Discovery: Founders Choose Fixed Price or Hourly Development

Default to fixed price when your scope is stable and the build is bounded. Default to hourly or time-and-materials (T&M) when requirements are still moving or discovery isn't finished. The pattern that works best in practice for most real projects is a hybrid: a capped discovery phase followed by fixed-price execution, once you actually know what you're building.

TL;DR:

  • Fixed price contracts include a 15% to 30% risk buffer to cover uncertainties, resulting in higher initial quotes for vague or unconfirmed specifications.
  • Hourly billing provides transparency and flexibility, but requires active management and a cap to prevent costs from drifting uncontrollably.
  • A hybrid approach with a capped discovery phase followed by fixed-price execution reduces risk and clarifies scope before locking in costs.
  • Clear acceptance criteria, named personnel, and a defined change process are essential contract components to prevent scope disputes and scope creep.
  • Most founders should start with a discovery audit to solidify requirements before committing to a fixed price, especially when the scope is still uncertain.
Hanad Kubat
Get a Fixed Build Scope
A Prototype Audit turns an uncertain software idea into a defined basis for a fixed-price build, with the audit credited against development.
Explore the fixed-price approach

Table of Contents

Fixed Price vs Hourly Development: The Core Trade-Offs

Fixed price means you agree on a total cost before work starts, tied to a defined set of deliverables. Hourly, also called time-and-materials, means you pay for actual hours logged against an estimate that can move as the work does. The choice comes down to three questions: how well do you know what you want, who should carry the risk if that guess is wrong, and how much oversight can you realistically do?

NetSuite's comparison of the two models puts it plainly: fixed price fits stable, clearly defined requirements where budget certainty matters most. Hourly fits work that's going to evolve, where locking scope early just means you'll be paying for change orders later. Upwork's guidance for hiring developers draws the same line, and recommends matching the contract type to the project type rather than picking whichever sounds safer.

Here's how the two models actually compare on the things that matter to a founder signing the check:

  • Budget predictability: Fixed price wins outright. You know the number on day one. Hourly gives you an estimate, not a ceiling, unless you negotiate one.
  • Flexibility to change scope: Hourly wins. You can redirect the team next sprint. Fixed price requires a formal change order, which costs time and often money.
  • Who bears overrun risk: Under fixed price, the vendor does, and prices accordingly. Under hourly, you do, which is exactly why governance matters so much more.
  • Speed of starting work: Hourly starts faster because there's no lengthy scoping negotiation before the contract gets signed. Fixed price needs a defined spec first.
  • Governance and reporting needs: Fixed price needs less day-to-day oversight, just milestone checks. Hourly demands active tracking, or the invoice will surprise you.

A short internal tool with a known workflow is a fixed-price candidate. A product still finding its market, where every user interview reshapes the roadmap, is an hourly candidate until that roadmap settles down.

What a Fixed-Price Contract Really Costs You

The number on a fixed-price quote isn't just labor plus profit. It includes a buffer for everything the vendor doesn't know yet, and there's always something. GMWARE's breakdown of fixed price versus T&M puts that risk buffer at 15% to 30% on top of the vendor's actual cost estimate. That's the price of certainty. You're not paying for more work. You're paying someone else to absorb the risk of being wrong about the work.

That trade shows up in the pros and cons pretty directly:

  • Pro: internal approvals get easier because finance sees one number, not a range.
  • Pro: the vendor eats the cost of underestimating, not you.
  • Pro: acceptance criteria have to be spelled out up front, which forces useful clarity before anyone writes code.
  • Con: you're paying for a buffer whether or not the project needs it.
  • Con: change orders turn adversarial fast, because every request now has a price tag and a negotiation attached.
  • Con: scope gets frozen at the exact moment you're least informed, which can block the kind of learning that improves a product.

Padding isn't dishonesty. It's math. A vendor quoting fixed price on a vague spec has two choices: pad heavily or lose money. The ones who pad least are usually the ones who insisted on a real spec before quoting, which is why a rushed RFP almost always produces an inflated number.

Fixed price saves you money when the spec is genuinely solid, the team has built something similar before, and there's little chance requirements shift mid-build. It costs you more when the spec is thin, because the buffer covers uncertainty that a proper discovery phase could have removed for a fraction of the price. Scopedocket frames the real difference as a matter of timing: fixed price decides the total before work starts, while T&M decides it only when the work stops. That single distinction is what drives everything else about who approves changes and who's accountable when the number moves.

How Hourly and T&M Billing Actually Plays Out

Hourly work runs on time logs and invoices, usually weekly or biweekly. A good vendor sends you a breakdown of hours against tasks, not just a lump total, so you can see where the time went. That transparency is the whole point. Without it, hourly billing is just an opaque number arriving at the end of the month, and by then it's too late to redirect anything.

The upside is real. You can change direction next week without renegotiating a contract. You start faster because there's no weeks-long scoping exercise before anyone touches code. And if the work turns out easier than expected, you pay less, something that never happens under fixed price, where the quote is the quote regardless of how the build actually goes.

The downside is just as real: hourly billing needs active management, or costs drift. Nobody's incentive is naturally aligned to finish fast, and a vendor paid by the hour has less reason to be efficient than one paid a flat sum. Disher's comparison of contract types makes the case that governance, not the billing model itself, is what determines whether T&M stays predictable or turns into an open-ended meter.

Three controls make hourly work safe instead of scary:

  1. Track weekly burn against the estimate. If a project was scoped at 200 hours and you're at 60 hours after week one, ask why before week two starts, not after the invoice arrives.
  2. Demand a working demo every sprint. Not a status update, an actual thing you can click through. If there's nothing to show, something's wrong.
  3. Set a not-to-exceed cap. This is the single best hedge against hourly's biggest risk: an estimate that quietly becomes a floor instead of a ceiling.

Pro Tip: Ask for a burn report before you sign, not after the first invoice. If a vendor can't show you what that report looks like from a past project, they probably don't track it closely enough to protect your budget.

The Hybrid That Actually Works: Capped Discovery, Then Fixed Price

Run a short, capped discovery phase first. Pay a fixed, small amount for a defined output: a written spec, testable acceptance criteria, and a risk register listing the unknowns that could blow up a quote. Then take that spec and get fixed-price bids on the execution.

Capped discovery flowing into fixed execution

This sequence solves the core tension in the whole fixed-price-versus-hourly question. You get the flexibility of an exploratory phase where things are genuinely uncertain, then you lock in the certainty of a fixed number once uncertainty is mostly gone. GMWARE's research on discovery-first approaches backs this directly: a proper discovery phase shrinks the risk buffer on the fixed-price quote that follows, because the vendor isn't pricing in unknowns anymore, just known work.

The discovery deliverables should be vendor-neutral, meaning you own them and can take them to a different vendor for the execution bid if you want to. That's a useful test of whether a vendor believes in their own discovery work: a confident one hands you a spec you could shop elsewhere.

A few mechanics make this hold together:

  • Cap discovery at a fixed price and a fixed timeline, no exceptions.
  • Define exactly what discovery must produce before anyone writes execution code.
  • Carve out a small percentage of the execution budget for change requests that still surface after discovery, since no spec catches everything.
  • Name who signs off on the discovery output before the fixed-price execution quote gets locked.

How to Choose: A Decision Checklist for Founders

Before you pick a model, answer four questions honestly. How stable is the scope, really? If you're still testing which feature matters to users, scope isn't stable, no matter how confident the spec looks on paper. Is there a hard funding ceiling? A board or investor who needs a fixed number for approval pushes you toward fixed price even if hourly would technically be cheaper. Who's your product owner, and how available are they? Hourly work needs someone checking in weekly. If that's not you and it's not anyone on your team, hourly gets risky fast. How many technical unknowns are still open? Integrations with third-party systems, uncertain data migrations, or unproven technical approaches all argue for discovery before fixed price.

At the bid stage, ask vendors these directly:

  1. Who signs off on change orders, and how fast does that turn around? A vague answer here is the single biggest red flag in a fixed-price negotiation.
  2. Can you show me a sample acceptance criteria document from a past project? If they can't produce one, they're not actually testing deliverables against anything concrete.
  3. Who is the named engineer doing the work? Not "our team." A specific person, ideally the one you're talking to.
  4. What counts as out of scope, in writing, before I sign? This single question prevents more disputes than anything else on this list.

Walk away if a vendor won't name the engineer, refuses to define acceptance criteria before the contract is signed, or gets defensive when you ask about the change-order process. Those are the three clearest signs a project is heading toward scope disputes later.

Pro Tip: If a vendor's fixed-price quote came back within 24 hours of seeing your one-page idea, that's not efficiency. That's a padded number built on guesses, not a spec.

The Contract Checklist to Bring Into Any RFP

Copy this into whatever statement of work or RFP you're drafting. IP assignment: the contract should state, in plain language, that you own the code and all deliverables from the first commit, not after final payment. Milestone acceptance criteria: every milestone needs a testable definition of done, not a vague description like "core features complete." Change-order process: specify the pricing method for changes, who has authority to approve them, and the turnaround time for a decision. Without this, scope creep becomes the default outcome, not the exception. Named personnel: the contract should name the actual person doing the engineering work, with language preventing an unannounced swap mid-project. Post-delivery support: define what happens after handoff. Is there a bug-fix window? A retainer option? Silence on this point almost always means you're on your own the day after launch.

My Approach in Practice

I work three ways: rescuing a stalled AI or no-code prototype, building a founder's first real version from a Figma file or a blank page, or turning one painful manual workflow into a tool your staff actually uses. Every engagement starts with a Prototype Audit, credited against the build if you move forward. Builds start from a stated price once scope is frozen. One name on the contract: mine. You own the code from the first commit, and I write every line myself, no juniors.

When a Certainty Premium Is Worth Paying

Pay the certainty premium when your board or your own runway math needs a hard number, not a range. Skip it and choose discovery-first when the real risk is building the wrong thing, not overspending on the right one. Most founders I talk to actually need both, in sequence, which is why the hybrid model exists in the first place.

— Hanad Kubat

Get a Fixed Number Before You Commit to Anything

The comparisons above assume you already have a spec good enough to bid against. Most founders don't, which is exactly why the hybrid model exists: pay for clarity first, then lock a number. That's what Hanad Kubat's Prototype Audit does. It's a fixed-price, three-to-five-day review that ends with a real assessment of what your prototype needs, and the fee gets credited against the build if you move forward. Builds start from a fixed price once scope is frozen at kickoff, with one name on the contract and no agency layer marking up the bill. If you're weighing whether to keep paying a no-code platform by the month or lock in a real number for a real build, start with the audit and see the actual scope before you commit to either model.

Sources

FAQ

Is fixed price or T&M better for a software project?

Neither is universally better. Fixed price works when scope is stable and you need budget certainty, while T&M suits projects that are still evolving. A capped discovery phase followed by fixed-price execution is usually the safest path for founders who aren't fully sure which camp they're in yet.

Should I pay a developer hourly or a flat rate?

Pay a flat rate when you have a written spec and testable acceptance criteria already defined. Pay hourly when the work is exploratory and you need the flexibility to redirect the team without renegotiating a contract, but only if you're prepared to track burn weekly.

What are the downsides of a fixed-price contract?

The quote almost always includes a risk buffer, typically 15% to 30%, to cover unknowns the vendor hasn't priced separately. Beyond that cost, fixed price can freeze scope at the exact point you know the least about what you're building, and change requests often turn into slow, adversarial negotiations.

How much does a fixed-price MVP build cost with Hanad Kubat?

Builds start from a fixed price once scope is frozen, with a Prototype Audit available first that gets credited against the build if you proceed. Exact current pricing is listed on the Hanad Kubat website.

Should I charge or pay hourly, or use a flat rate, for ongoing development?

For a one-time build, fixed price or a capped hybrid usually works best once scope is clear. For ongoing, long-term work, neither fixed price nor pure hourly aligns incentives well, and a subscription or retainer model often fits better once the initial build is done.