How to prepare a blockchain project for a fixed price estimation?
If you're a client, a fixed price for a software project sounds very tempting. Hypothetically, there's no risk of exceeding the budget, you have a clear deadline, and the responsibility is entirely on the agency's side.
But let's imagine a scenario in which you approach a software development company (like ours) with an idea and ask for cost estimation. Immediately, without hesitation, you hear a response:
"It will cost somewhere between $20 000 and $2 million."
What went wrong? Did you say something crazy? Is this real life??
You're certainly not dreaming, but the fact is, it takes more than just an outline of an idea to get an actual price. And we know, blockchain projects usually are very strong on ideas (the execution part is where it gets difficult).
In this article, we will explain how to prepare a blockchain project software concept for cost estimation to get the most accurate and lowest possible price. And we'll answer another crucial question, which is, "Is a fixed price model surely the best option for your project?"
Why are fixed-price estimates inaccurate or higher than they should be?
Unfortunately, fixed price estimates tend to be higher than expected, usually because the project requirements and specifications are not… specific enough. Without the precise requirements, software houses have to limit the potential scope-related risk and include a significant financial safety net in the estimate. And for complex and long-term projects, even that might not be enough, so software agencies tend to avoid it. Of course, some agencies still would happily agree, but in this case, the question is: “Are you ready to trust someone who’s willing to take on a project with so many uncertainties?.”
In an ideal world, a client knows exactly what the project is supposed to be, knows the ins and outs, and can put it on paper in the form of a Product Requirements Document (PRD). In reality, it isn't always possible to write a precise outline of all project specifications, especially if you're a startup dealing with cutting-edge technology on uncharted territory.
For these exact reasons, we highly discourage our blockchain clients from choosing fixed-price contracts, as they clearly don’t fit their requirements. If you’re operating in a highly competitive and dynamic industry, you need flexibility and the ability to react to changes asap.
Are you sure the fixed-price model is suitable for you?
The essence of the issue is that estimates are based only on the available information, and they're adjusted for areas of the project outline that are not specified and unexpectable. The more unknowns and blank spots there are in the project, the more expensive the estimate will be. This is why we recommend a fixed-price project primarily for early-stage/MVP (Minimum Viable Product) versions with a smaller scope of work and a limited number of features.
Let's say you have a software project at hand. You have a set budget and a deadline, so the next obvious step is to contact a few agencies for an estimation request.
Well, not necessarily.
First, you should decide if the fixed software development pricing model is undoubtedly the best option. You might think that it comes with the lowest risk, but there are always pros and cons, such as lack of control in this method (or at least less influence on the process).
Most importantly, you should ask yourself, is the fixed pricing model a correct approach for your type of project? There are a few questions that can help you decide:
1. What's the purpose of the project? Are you ready to build the final product, or you're at the stage of attracting investors?
If your project aims to build the MVP version and acquire more financing, fixed pricing may be perfect. We also recommended it if the product may require much testing before release (or even being released as an early version). In this case, it's best to build a beta version of the product, release it to testers or early adopters, gather feedback, and make successive iterations with a better understanding of market demand.
On the other hand, the more complex a project, the more reasonable the time & material pricing method is. If the development phase is estimated at longer than six months, it's almost sure that the fixed pricing method will be simply insufficient.
2. How precisely can you predict the final outcome? Do you expect many changes during the development process?
If you're not ready to answer most questions about how the end product will look and work, you might have to switch to the time & material pricing method. Without a clear vision of the product or software, the agency most likely won't be able to give you an accurate estimate, which usually means higher costs. Unclear requirements will have to be accounted for in the time estimation, even if the actual time spent on the project by the development team will end up being much shorter.
And after all, be honest with yourself. If you have a trailblazing blockchain project at hand, you probably are not ready to outline the whole process start-to-end. The most crucial thing is to start the project and steer it as you go.
3. How much influence do you want to have on the project?
Remember that this model not only determines the actual price but significantly affects the process. With the fixed price, you will have far less influence on the development process because all the requirements are set beforehand in the fixed-price contracts and PRDs. That means three elements of the Project Management Triangle (scope, time, cost) are also predefined. Of course, it doesn't mean you won't be able to change the project’s direction in the middle, but you will have to pay extra.
4. How big is your project?
Most software development agencies (including us) won't agree to a fixed-price contract model for a big project without a significant safety net. The scope-related risk is too high, and it's too difficult to predict all stages of development, so the only way around is adjusting for a lot of additional costs. Additionally, a fixed-price contract for a big project requires a lengthy and costly planning phase. It takes time to outline the process, discuss it, and finally accept. The short answer is: if you're in for something big, it's better to go for time & material (unless you're ready to pay a lot and go through an extended planning phase).
What do you need to prepare for the agency to get the most accurate and the cheapest estimation?
So it's settled. You're confident that the fixed-price approach is perfect for your project, and you're ready to ask for a price. What are the initial requirements that the software house needs to know about the project to estimate precisely?
Detailed specification (preferably in the form of PRD)
This is the most crucial information that will help the software house prepare an accurate time and price estimate. The more specific it is, the better. Detailed documentation will spare the client unnecessary costs and help the software house team with quick and efficient project development. It will also help estimate how big the development team is required and what skills are necessary to deliver the project. In some cases, the software might require developers with experience in the given industry.
You can read more on how do we choose the best developers here.
The bread and butter of software development projects. Acceptance criteria are usually included in the PRD. They should contain all the requirements that must be delivered for the project to be considered done and accepted.
If you're short on time, you have a deadline from the investor, you promised a certain date to the community, or perhaps you are in rush to showcase your product at a conference. Whatever is the reason, make sure to let the software company know about it. It will be an immediate red light for some of them, and it's best to learn it right away.
Of course, if you don't have any definite deadlines, the software house will prepare a suitable schedule. On some occasions, though, if the process becomes complicated and time-consuming, the company may insist on a different type of contract because the project is not fit for a fixed-price model.
Providing mockups of how the product should look like beforehand will be a massive help for cost estimation. On the other hand, if you don’t have designers on board, we can discuss your vision and prepare mockups for you, but it obviously takes time and adds to the final cost.
List of features
It would be perfect if you were able to deliver a complete list of necessary features. Of course, it doesn't mean they all have to be implemented in the MVP version, but it's good to prepare developers for their future implementation and allow them to lay the groundwork.
To start, we recommend making a simple feature spreadsheet and marking the necessary ones. Remember, adding features during the development process will involve extra costs.
You have to know how much you can spend on the project, but of course, it's the software development company's role to say how realistic it is to make it within the budget.
Remember, though, that the more precise your requirements are, the lower price you'll receive.
What else can affect the price?
All of the elements mentioned above will be crucial for the estimation, but a few more things can increase the final cost of the software. Factors such as particular skills necessary for the project or an unusual technical approach are always factored in individually, case by case.
Would you like a fixed-price estimate for your software project?
Judging by the fact that you've reached this part of our blog post, I am assuming that you might have a project you would like someone to estimate.
Of course, you've come to the right place.
You can schedule a call with me here. I will be more than happy to hear about your project and prepare a precise estimate (or advise a different pricing model).
I'm sure we'll be able to find the best solution.