Fixed Price vs Hourly: How to Choose the Right Pricing Model for a Freelance Web Project

One of the projects that changed how I think about fixed pricing was a $4,500 website rebuild that looked perfectly reasonable when I quoted it.

The work itself was not unusually difficult. I understood the stack. The client was easy to deal with. I expected the project to run for about six weeks.

It lasted almost four months.

Content arrived late. A second stakeholder became involved after the project was underway. Pages I thought had been approved came back for another pass. Small requests kept appearing, and none of them looked large enough on its own to justify turning the relationship into a fight over scope.

By the time the site launched, the problem was obvious. I had not priced the project badly because fixed pricing was inherently wrong. I had priced uncertainty as though it did not exist.

That distinction is the useful place to start when deciding between fixed price and hourly billing.

Freelancers often talk about the choice as though it reflects a philosophy. Fixed-price developers say they should be paid for the result rather than the hours. Hourly developers say they should not absorb work they could not reasonably predict. Clients often prefer a fixed number because it gives them something concrete to budget.

All of those positions can be sensible. None of them tells you which model belongs on a particular project.

The pricing model is really a decision about who carries the financial consequences when reality differs from the estimate.

Fixed price is a promise, not just a number

When you quote a fixed price, you are doing more than choosing a different way to calculate the invoice. You are agreeing that a defined obligation can be completed for a defined amount.

That can be a very good deal for both sides when the obligation is genuinely understood.

Suppose you build a certain class of marketing site repeatedly. You know what the normal design and development work looks like. The client is responsible for final copy before implementation begins. The integrations are familiar. The review process is defined. You know what counts as complete because you have delivered similar projects many times.

In that situation, charging by the hour can actually obscure the value of experience. If you have become faster because you know where problems usually occur, there is no particular reason your revenue should fall simply because you are better at the work.

A fixed price lets the client buy the agreed result while you keep the benefit of efficiency.

The problem begins when the promise is much clearer than the work underneath it.

A client may ask for a fixed price to rebuild an internal application, but the workflows are still being discovered. The existing data has not been inspected. Nobody is entirely sure how permissions work. A third-party system has to be integrated, but the client’s team cannot yet explain the edge cases. Several stakeholders will have approval authority.

You can still put a fixed number on that project. The presence of a number does not make the project more knowable.

You have simply taken a set of unresolved questions and converted them into financial risk.

That is what I had done on the $4,500 project. The project did not blow up because one dramatic feature appeared. It stretched because too many parts of the engagement were allowed to remain soft: review, content timing, stakeholder involvement, and what happened after something had supposedly been approved.

The quote assumed a cleaner project than the one I had actually agreed to run.

Hourly billing does not mean the project is unmanaged

Hourly pricing is often criticized because it appears to reward time rather than outcomes. There is some truth in that criticism when the engagement is poorly designed. A client should not have to accept an unlimited meter simply because the developer does not want to estimate anything.

But there are projects where time-and-materials billing is the more responsible commercial structure precisely because the work cannot yet be bounded honestly.

Troubleshooting is the obvious case. A production problem may take forty minutes to diagnose or two days. The symptoms tell you that work is necessary; they do not tell you how much work the investigation will uncover.

Legacy systems create the same problem. A request that sounds small from the outside can become materially different once you see the code, the data, and the dependencies. So can exploratory product work, technical remediation, migrations, and projects whose direction will continue to change as the client learns.

In those situations, hourly billing keeps the uncertainty visible.

That does not remove the need for commercial discipline. The client can still have an expected range, an authorized amount of work, regular reporting, and a point at which you stop and discuss what has been learned before more money is spent.

The difference is that neither side is pretending the amount of work is already known.

This is where the usual argument about “selling time” becomes too simplistic. Sometimes time is not what the client ultimately values, but it is still the fairest unit for work whose shape has not stabilized.

Clients are not wrong to want certainty

A client asking for a fixed price is not necessarily trying to push risk onto you. They may have a budget to approve, a board to answer to, a cash-flow limit, or an internal deadline attached to a known spend.

The mistake is assuming that their need for certainty creates certainty in the project.

If a client wants one price for a rebuild that includes migrating data nobody has inspected, there are only a few ways to give them that number. You can guess low. You can guess high. Or you can hide a large contingency inside the quote and hope it covers whatever you eventually discover.

None of those choices changes the condition of the data.

A better commercial answer may be to separate the decision into stages. The understood portion can be priced. The uncertain portion can be investigated first. Once the investigation has turned unknowns into evidence, you can decide whether the next phase is stable enough for a fixed commitment.

That is one of the reasons paid discovery can be valuable. It is not simply another thing to sell. It creates information that can make the later pricing decision more honest.

The same logic works in the other direction. If a project is genuinely routine for you, continuing to bill hourly just because a previous fixed project went badly may be an overcorrection. You may be asking the client to carry uncertainty that you, not they, are best equipped to understand.

The question is not which model feels safer. It is which model matches the uncertainty that remains after you have done reasonable discovery.

Fixed price gets dangerous when interpretation becomes part of the margin

There is another reason badly bounded fixed-price work becomes uncomfortable.

It changes the incentives inside the relationship.

Once the developer realizes the project is consuming more effort than expected, every ambiguous request begins to look like a threat to margin. The client, meanwhile, has already agreed to a total price and may reasonably believe that some of those requests were included in what they bought.

Now both sides have a financial reason to interpret the original agreement in their own favor.

That is how a technical conversation turns into an argument about wording.

Strong fixed-price work avoids a lot of this by making the obligation clearer before the work starts. You do not need to predict every implementation detail, but you do need enough agreement around deliverables, assumptions, dependencies, revisions, exclusions, and completion that the price is attached to something real.

This is why acceptance criteria and scope control matter so much in fixed-price work. They are not administrative extras added after pricing. They help define what the price actually covers.

Hourly work has its own failure mode. If the engagement has no priorities, no budget visibility, and no stopping points, the client can feel as though they approved an open-ended commitment. The fact that every hour is technically billable does not make that a well-run project.

In both cases, the billing model works only when the project itself is managed.

Some projects should use more than one pricing model

A surprisingly common mistake is forcing an entire engagement into one commercial structure even though different parts of the work carry very different levels of uncertainty.

A project can begin with a short, bounded discovery engagement. That discovery may produce enough evidence to price the main implementation at a fixed amount. A legacy integration inside the same project may still be better handled on a time-and-materials basis because it cannot be made predictable without actually working through it.

There is nothing incoherent about that.

You are not choosing a permanent identity as an “hourly freelancer” or a “fixed-price freelancer.” You are deciding how each obligation should be priced based on what is known when the commitment is made.

I increasingly think of this as one of the marks of commercial maturity. Early on, I wanted one pricing rule I could apply to everything. It felt cleaner. In practice, the cleaner answer is often to admit that one part of a project is understood and another part is not.

That is better than disguising uncertainty with a large contingency or pushing the whole project into hourly billing because one component is unpredictable.

Value matters, but it does not make uncertainty disappear

There is a separate pricing conversation about value, and it belongs here only because it is easy to mix the two questions together.

The commercial importance of a project can absolutely affect what it is reasonable to charge. A technically simple change that removes a meaningful business bottleneck may be worth much more to a client than a larger piece of work with little consequence.

But the value of the result does not tell you whether the delivery risk should sit with you or with the client.

You can set a fixed project price partly in relation to commercial value and still need strong scope because you are assuming the risk of delivering the promised result for that amount. You can also work on an hourly basis when the project has enormous business value because the path to the result is still uncertain.

Value influences price. The billing model influences how uncertainty is handled. They are related, but they are not the same decision.

The choice becomes easier once you stop asking which model is “better”

I do not think there is a professional progression where freelancers begin hourly, become sophisticated enough for fixed pricing, and eventually graduate into some higher form of pricing. That idea makes people choose models for status instead of fit.

The useful questions are more ordinary.

How well do you understand the work? How stable are the requirements? What dependencies sit outside your control? How much of the uncertainty can be reduced before you commit? If your estimate is wrong, who is in the better position to absorb that risk? And does the structure give both sides a sensible way to respond when new information appears?

Once those questions have real answers, the billing model usually stops being mysterious.

Fixed pricing is strongest when the promise is bounded well enough that you can responsibly own the delivery risk. Hourly or time-and-materials work is strongest when useful work can begin but the amount of work cannot yet be known honestly. A hybrid arrangement makes sense when different parts of the engagement deserve different treatment.

The lesson I took from that $4,500 project was not “never quote fixed price again.”

It was that a fixed price should be the end of understanding, not a substitute for it.

For the broader pricing decision—your economic floor, whole-engagement effort, risk, commercial price, payment structure, and pricing policy—the Web Developer Pricing System goes much further. The point is to make those decisions deliberately instead of inventing a new rule every time a prospect asks what something will cost.