Clients often ask for one number before the system has one answer.

“How much will this app cost?”

The honest response depends on what is known, what can change, and who owns the uncertainty.

Fixed price and hourly work are not good-versus-bad models.

They place risk in different places.

Fixed price works for bounded outcomes

Fixed price is a good fit when:

• the user and workflow are known;
• scope is explicit;
• acceptance evidence is testable;
• dependencies are stable;
• design is approved;
• content and access are ready;
• exclusions are written;
• change control is understood.

The client buys a defined outcome.

The developer prices delivery risk.

If the scope is genuinely bounded, this can be comfortable for both sides.

Fixed price fails when discovery is hidden

A fixed quote becomes fragile when:

• the existing code has not been inspected;
• provider behavior is unknown;
• data needs migration;
• design is still changing;
• stakeholders disagree;
• “MVP” means an expanding idea;
• acceptance is subjective;
• production access is unavailable.

The number may look certain.

The project is not.

Someone eventually pays for that gap through shortcuts, disputes, or unpaid work.

Hourly works for evolving systems

Hourly or time-and-materials work fits:

• diagnosis;
• legacy modernization;
• ongoing product development;
• incident response;
• research and prototyping;
• changing priorities;
• maintenance;
• work where each finding changes the next step.

The client buys focused capacity and transparent decisions.

That requires strong reporting.

Hourly without visibility feels open-ended.

Hourly with a clear backlog, cap, update rhythm, and decision log can be highly controlled.

The hybrid model I prefer

For uncertain work:

Phase 1: paid discovery

Bounded time and outputs:

• system map;
• risks;
• scoped path;
• assumptions;
• representative technical check;
• estimate or delivery options.

Phase 2: defined milestone

Fixed price where the discovery made the outcome clear.

Phase 3: controlled iteration

Hourly or retainer for learning, changes, optimization, and support.

This prevents a fictional fixed quote from carrying unknown architecture.

What every model still needs

Regardless of price model:

• outcome;
• scope;
• exclusions;
• acceptance;
• dependencies;
• ownership;
• communication rhythm;
• change process;
• payment schedule;
• pause/cancellation terms;
• handoff;
• support boundary.

Pricing does not replace project design.

Use caps and checkpoints

Hourly work can include:

• weekly cap;
• approval threshold;
• milestone review;
• spend alert;
• stop condition;
• prioritized backlog;
• forecast range.

Fixed work can include:

• milestone payments;
• change-request process;
• client-decision deadlines;
• acceptance window;
• dependency assumptions;
• expiration of the quote.

Control is possible in both.

Compare proposals by assumptions

Two quotes can differ because one includes:

• testing;
• deployment;
• data migration;
• responsive states;
• accessibility;
• documentation;
• post-launch support;
• provider fees;
• security hardening.

The other may not.

Compare the work model, not only the total.

Ask:

What must be true for this quote and timeline to remain valid?

The answer reveals the risk.

My decision rule

I use fixed price when the outcome and boundary can be described well enough to price responsibly.

I use hourly when investigation and change are the work.

I use a hybrid when discovery can convert uncertainty into bounded delivery.

The right model does not eliminate change.

It makes change visible before it becomes conflict.

For scope design, read how I turn requirements into shippable scope. For selecting a developer, read the Bangladesh hiring guide.

If you need an estimate, send the outcome, current system, deadline, and what is still unknown.