Published
Reading time
9 min
Category
- Insight
Published
Reading time
9 min
Category
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?”
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.
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:
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 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.
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:
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.
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.
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.
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.
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:
Like all models, the target price model demands meticulous documentation, clear agreements, and strong project management.
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.
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.
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.
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:
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.
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.
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.