Time-and-material or fixed price: how to choose a pricing model for a blockchain project?
When it comes to pricing, people naturally prefer the straightforward way. We pay X dollars, and you deliver the product. Plain and simple. But when it comes to software, especially blockchain and other innovative technologies, it’s rarely the best option, and sometimes it’s not an option at all.
In this article, we’ll dive into the subject of software project estimations, and we’ll answer a couple of crucial questions:
- How to choose a pricing model for a blockchain project?
- How are pricing models influencing the development process?
- How to get the lowest estimate possible?
To put it simply, let's talk about money and how to spend it wisely.
The difference between pricing models
Let's start with the basics. How exactly do the two most common software development pricing models work?
Time & material model (T&M)
In this model, a software house doesn't prepare an estimation for the whole project but is charging for the actual time spent on it by the development team and project managers. It doesn't require documentation with the exact scope and initial requirements, so the planning stage is far less time-consuming. If you have a brilliant idea for a groundbreaking blockchain platform, and time is of the essence, you can stop reading now. Time & material is for you. Here's a contact form, let's discuss it and get to work asap. Just kidding… I hope you’ll find useful information that will help you to decide which model is for you.
Time & material is also perfect for clients that need to be involved on a daily basis, monitor the project progress, and steer it in the right direction. From our experience, the most effective approach for blockchain projects is appointing a Product Owner who works directly with the software developers and provides priorities and regular feedback.
When to choose time & material contract?
We use the word "choose," but the choice is not always on the client's side. Many software development companies are not making fixed-price estimations as a rule for different types of projects. For example, we would be very enthusiastic about working on a cutting-edge, ambitious blockchain project with an extensive scope of work, but if we were asked for a fixed-price estimation for it as a necessary prerequisite, our enthusiasm would plummet like the bitcoin price after one of Elon Musk's tweets.
From the client's standpoint, there are certainly more pros than cons of T&M, making this pricing model the most common on the market. For some types of projects, though, it is simply the only option that makes sense.
- Long-term cooperation or projects with a broad scope of work
For the projects that require a long-lasting relationship between the client and the development team, T&M is a no-brainer. When the total project scope is unknown, the Product Owner on the client's side can oversee the product development and balance the workforce according to current needs. And if there's an additional budget, we can increase the team size and speed up the progress.
For the ongoing support, there's also a tweaked version of the method. There can be a monthly/yearly budget limit, which can be updated during the development.
- Projects that require flexibility
There's a tool in the time-and-materials model, which we like to call "micro fixed price." If there's a flexible budget, the project development can be planned virtually on the go, thanks to the agile approach. If the progress is divided into iterations, it's possible to create flexible requirements, set milestones, and modify the budget according to the current needs.
It's a perfect pricing method for innovative technologies, prone to dynamic market changes and legal regulations, such as blockchain. It provides much-needed flexibility to shift focus in the project or implement additional features.
The same aspects are invaluable for projects in which the full scope is not perfectly clear yet, such as cutting-edge projects in a highly competitive market. It allows startups to quickly begin the development process without the planning phase when there's a risk of being outrun by rivals.
It's a simple method in which a software house estimates the project's cost beforehand and gives a total price for the delivery. It puts more responsibility on the agency but takes away control from the client. Once the requirements are set, the client's influence on the software development process is limited. What matters is the product specification established in the contract. Of course, it doesn't mean there's no way to change the course of action in this model, but it almost certainly will result in additional cost (and possibly legwork).
When to choose a fixed-price contract?
- Straightforward projects with limited scope
The estimation in the fixed-price project is based on all the information received by the agency, which means it accounts for everything that's known, plus all the uncertainties and blank spots. The more gray area there is in the project, the more expensive it will be because the agency has to take into consideration the unexpected difficulties. Of course, if you can design a precise project description with detailed requirements, complete scope, and a list of features, that's great. Your product sounds suitable for a fixed-price type of contract.
We elaborate a bit more on this topic in the article "How to prepare a software project for a fixed-price estimation?"
For complex projects, there is also a planning issue. The longer the expected time is, the more suitable is the waterfall approach, which means that in order to prepare the estimate, it's necessary to outline the entire development process start-to-end, which in itself is time-consuming. Therefore, it needs to be paid for.
Additionally, more extensive projects bring to the table the ever-present issue of time estimation. While it's relatively easy to evaluate the necessary technological expertise for a task, it's far more challenging to estimate the time required to complete it. This problem escalates with the more considerable scope and often leads to missed deadlines and wasted budgets, so it's another reason why software development teams rarely recommend fixed-price for complex projects. In fact, the bigger the project, the more spectacular failure can be. For example, take a look at one of our favorite lists on the internet: “List of failed and overbudget custom software projects”, which includes projects such as the NHS Electronic care records system (close to 10 billion over budget and discontinued) or American Healthcare.gov project, which ended up costing over 1,5 billion after being estimated at 93,7 million.
- MVPs, prototypes, early-stage, and other short-term projects
On many occasions, especially for blockchain-related projects, the business goal at hand is to release a minimum viable product (MVP) to test the market and gather more investors. Projects like this usually are much more predictable and have limited features, so they're much easier to estimate.
You may also find some articles that recommend this model for clients with a limited or fixed budget, but it doesn't always prove to be a correct approach. You might say that the fixed-price contract is budget-friendly because you are given the project costs, and the software company deals with all the rest. Hypothetically, yes, but what if your planning process wasn't as thorough as you thought? What if you suddenly need to change the business strategy due to some unexpected circumstances? Suddenly, it may turn out that the necessary changes are pretty significant, and the initial budget is insufficient. What makes it even worse, any changes in scope or budget require a contract appendix, which also takes time. The T&M model provides much more flexibility in such situations. For all the reasons above, clients that previously worked with us on fixed-price contracts usually tend to change to T&M after a while.
Generally speaking, though, the budget shouldn't be the decisive factor in choosing a pricing model. The project requirements and scope should be, which leads us to the big question.
Which pricing model will be the best for my project?
Now focus because we're about to drop the absolute fact-bomb.
Are you ready?
Do NOT choose the type of pricing you "like." Choose the one that's RIGHT for your project.
Obviously, you don't need to know which one's the best right away. You can ask us, and we'll surely help you find an answer. And trust us, we know that sometimes the good ol' fixed-price type of contract might be a preferable option in your organization, but more often than not, it just doesn't make sense financially.
But let's not get ahead of ourselves. If you have a software project at hand, we are here to help. Use the form here to schedule a call with me, and we will help you fit the pricing model to your business requirements.