Jump to content

Published

Reading time

9 min

Category

  • Insight

The 5 Most Common Pricing Options For a Website

Author

Aapo Mäki

The pricing models for websites, online stores, and applications are diverse, and projects can be priced in various ways. I believe this often leaves buyers more confused with their thoughts. It must be difficult to make a purchase when the a) contents and b) pricing models of offers vary significantly. In this article, I will outline five key pricing options.

My name is Aapo Mäki, and most of my work time is spent selling various web service projects to small, medium, and large companies and other organizations. For example, to Burger King, Retta, S-Group, and the Teollisuusliitto.



“Who is actually capable of handling this project, how, and at what price?”

1. Fixed price

A comprehensive website redesign with a truly fixed price, without the risk of going over budget? This pricing model is rare in the industry. It requires confidence and expertise from the provider, and on the customer side, proper engagement during the request-for-proposal phase.

Conditions for Fixed Price

For any sensible provider to offer a fixed price for a website redesign, it is essential to know exactly what is being offered (i.e., what is being done) during the sales phase. This requires at least one of the following:

  • The customer is very knowledgeable, and the request for proposal (RFP) is detailed and comprehensive.
  • The provider performs initial planning and can describe accurately and clearly what the customer needs and why. Once the exact scope is understood, the workload can also be estimated. Or at least, it should be.
  • The customer discloses the budget openly and demands a fixed price. In this case, providers will make their best estimate and provide an offer at a fixed price.

When to Offer a Fixed Price

In my opinion, most basic web projects should be offered with a fixed price, as long as at least one of the conditions mentioned above is met. A skilled provider should be prepared to take on the risk of potential scope overruns. As long as the provider is given the conditions to know (or propose) exactly what is being done.

It is also very important that the customer understands what a fixed price means. The price is fixed as long as nothing new or extraordinary is introduced during the project. What counts as “new and extraordinary”? Well, anything not specified in the offer. To avoid ambiguity or misinterpretations, offers and contracts in fixed-price projects must be very detailed.

We and Fixed Pricing

We offer basic web services at a fixed price. However, this also means we need to be more meticulous than your typical vendor candidate during the proposal phase: we ask questions, seek clarifications, make suggestions, and challenge assumptions. In other words, we don’t charge into a project unprepared.

Despite all this, there are times when fixed-price projects hit us hard financially. And when that happens, it’s our profitability—not the client’s—that takes the hit. Fairly so.

Offering fixed prices and providing detailed solution descriptions typically create excellent conditions for successful project execution. This applies not only to the budget but also to the schedule and resource allocation.

2. Partially Fixed Price

The same as above, but with a few exceptions. As projects grow in size, it becomes more likely that, during the proposal phase, it is not possible or reasonable to define, for example:

  • How a very complex individual feature will be implemented. For example, a user-dependent purchasing journey.
  • What API solutions a third-party system provides and how data mapping between systems will occur.
  • The customer and/or provider simply may not yet know or be able to know what content types (such as pages, articles, events, people, services, products) the upcoming website will require.

In larger web projects, there may be details that are neither appropriate nor practical to clarify during the request-for-proposal and proposal phase.

However, this does not mean that the proposal should be entirely an estimate that will be refined later. In this case, we recommend requiring a partially fixed-price proposal, where open details can be clarified later as estimates or fixed work-range estimates.

We and Partially Fixed Pricing

In our medium and large-scale web service projects, we often identify details that are not reasonable—or even practical—to define precisely during the proposal phase. In these cases, we provide a partially fixed-price offer. The evolving details are presented as either estimates or fixed price ranges.

Even in such cases, it’s crucial that the proposal is clear and detailed. The client must fully understand how the pricing is structured and what factors influence it.

3. Target Price

The target price model is well-suited for increasingly larger web development projects. However, it requires strong trust between the client and the provider. This model might include terms such as:

The project’s target workload and budget is set at 100 person-days (PD) and €80,000 (excl. VAT), equating to €800/PD.Underutilization: If the provider completes the work in less time than the target workload, they are entitled to invoice the actual workload plus 50% of the difference between the target and actual workloads.

  • Example 1, underutilization: The provider completes the project in 90 PD instead of 100 PD. The actual workload billing is €72,000. Additionally, the provider may invoice 50% of the €8,000 difference, equaling €4,000. The total invoice becomes €76,000.

Overrun: If the project exceeds the target workload, the provider is entitled to invoice only 50% of the additional workload up to 20% beyond the original workload. Any excess beyond the 20% overrun is non-billable.

  • Example 2, overrun: The provider completes the project in 120 PD instead of 100 PD. They may invoice the target price of €80,000 plus 50% of the additional 20 PD, calculated as follows: €80,000 + (20 PD * €800 * 50%) = €88,000.
  • Example 3, significant overrun: The provider completes the project in 150 PD. They may invoice the target price of €80,000 and 50% of the additional workload up to the 20% overrun limit (120 PD). Beyond this, no further invoicing is allowed. The total invoice is identical to the previous example: €80,000 + (20 PD * €800 * 50%) = €88,000. In this scenario, the provider is unable to invoice for 20 PD * €800 * 50% + 30 PD * €800 = €32,000 of their actual workload.

Why Use the Target Price Model?

The target price model requires clarity on the main objectives and scope of the project. The provider must commit to designing and delivering all critical features and functionalities within the target price framework. Its key advantages include:

  • Detailed definitions of all functions and features are not required during the request-for-proposal phase.
  • The client and provider can collaboratively prioritize and decide if a newly identified feature fits within the target workload.
  • The model incentivizes the provider to work efficiently.

Like all models, the target price model demands meticulous documentation, clear agreements, and strong project management.

We and the Target Price Model

Some projects are inherently such that it’s important to leave flexibility in the scope during execution. The target price model is ideal for large and complex projects where the exact requirements are not fully known at the time of contracting.

We utilize the target price model in our most extensive projects.

4. Cost Estimate

A cost estimate means exactly that: the offer represents an estimated cost. The final cost may end up being higher or lower than the estimate. This model shares similarities with the target price model but without any upper or lower boundaries.

The cost estimate model can be challenging for both project managers and clients, especially if the offer doesn’t clearly detail what the project includes. Even if it does, clients are likely to feel frustrated if, for example, a search function ends up costing €3,000 instead of the estimated €2,000 without a clear justification.

In my view, the cost estimate is the most common pricing model in our field—and often the worst from the client’s perspective. I’m fairly confident that this model contributes to stories from clients about how “no previous project has ever stayed within budget.” For providers, however, this model can be delightful, as it allows them to initially provide an estimate and ultimately bill for all the work performed.

We and the Cost Estimate Model

From the customer’s perspective, the cost estimate model often feels challenging:

1. If we know what we’re doing, why doesn’t the provider use models 1–3?

2. If we don’t know what we’re doing, why even attempt an estimate? In such cases, the next model (5) would be more appropriate.

Feel free to submit a request for proposal using the button below—though it’s unlikely we’ll offer you a cost estimate-based project.

5. Hourly Billing

There are also projects where there’s no attempt to define, design, or estimate in advance. In certain rare cases, this model can be useful:

  • The specifics of what and how to deliver are entirely unknown. The goal is simply to “rent” experts who will ultimately deliver service X.
  • The actual time spent, cost, or schedule is of little importance.

In most projects, there isn’t a strong case for using this model. However, in maintenance and ongoing development tasks, it can sometimes make sense—but that’s a different matter. Once again, from the provider’s perspective, this model is convenient, but for the client, it carries significant risks in terms of both cost and timelines.

In more substantial software development projects, this model is often justifiably applied. However, for web service projects, it’s typically possible and reasonable to determine what’s being delivered during the agreement phase. As such, there’s rarely a strong justification for using this pricing model.

We and the Hourly Billing Model

If you’re not quite sure yet what you want to achieve or when, feel free to give us a call. We’ll likely find a way to utilize one of our other pricing models previously described. That said, we’re more than capable of working and billing on an hourly basis when necessary.

Summary

In our view, the client must clearly know what they are purchasing and at what cost.

Options 1-3 are good or excellent, depending on the project. Option 4 is not something we typically prefer. Option 5 works in a select few cases.

Aapo Mäki
Aapo Mäki

CEO / Senior Service Designer