When you are looking to get a quote for your software project, the most important thing you can do is undergo a thorough estimation process (no matter if we're talking about a mobile app, a web app, blockchain components, AI, IoT project etc).
That's why the last couple of weeks I made it a personal mission to research, pull from my own experience with clients or partners, and write this article. Because I want to make sure that anyone (tech-savvy or not) can fully understand the whole picture when they ask for a quote and why this so important for the success of the product.
After reading this piece, you'll get valuable know-how so as to:
- make better business decisions that actually reflect a clear timeline.
- understand what are the basic aspects you need to know before starting a development project.
- avoid spending money where you can prevent it.
All the know-how I’m writing about has been acquired across 13 years of experience in the software industry, by my team at Around25. You’ll understand it even if you don't have enough experience in the market. Because I’m sure you’re qualified to figure out what’s best for you.
Topics I’ll touch upon:
- Why "I need a quote" is not enough when you want to get an estimate from your software partner;
- Why following a rigorous estimation process can save you thousands of dollars; (check it)
- How technical documentation and designs reflects in your budget, time, plan and professional relationship; (check it)
- Types of agency pricing model and which one suits you; (check it)
- The estimation process you should follow in order to save you a ton of money and time; (check it)
1. "I need a quote" is like saying "I want to buy a car that has never been in the market"
To most of our clients, estimating a development project is like buying a car, where they are the buyers and we are the car dealers.
You may have some expectations from the car dealers, but they are not mentalists to read your mind and to guess whether you want an SUV or a sedan. Or guess whether this SUV should be a Volvo XC90 instead of a Range Rover Phev. Or guess which - from 500 features a car might have - are the specific 378 you need.
You actually need to talk to the car dealer about those 378 requirements.
Just like you actually need to talk to your software partner about the 378 things you want your product to do.
That’s why it’s important to go forward with your research, get to know potential software services providers, see how they work, and find if there’s a match between both of your value sets.
A frequent mistake company owners do is speeding up this research phase just to immediately get a quote.
A software agency is there to help you build the project you want, not talk you into buying their services no matter what. This means a software partner will:
- prepare you for and guide you through the entire process of building a product.
- ask as many questions as needed in order to build an accurate timeline for development (this step will help you avoid missed milestones and delayed releases along the way).
- be honest with you when it comes to the implementation of the project in order to not overpromise and underdeliver.
Check what our past clients think about this approach and the way we work:
2. How to Gear Your Engine the Right Way
Ideally, you will get into an estimation process with a product development agency only when you have a detailed technical documentation and clickable designs. This is critical to have because a clear design of you mobile application defines the experience a user will have on your platform.
This way, you will be more in control of the project, which gives you the chance to decide if you break down the platform in versions (v1/v2/v3) and prioritize the features, decide what is a nice-to-have feature and what is a must. Also, you can get separate proposals for each version, which helps you pace your overall roadmap better.
This stage is the discovery stage where you have the chance to make better business decisions.
Let’s spell out all the most important reasons why.
Remember what I said earlier about how getting a quote is the same as buying a car? In the next lines, I’m going to use this analogy to illustrate the factors that influence the budget for a software project.
Imagine you bought a car without going through its technical manual. You get home, you go for a test drive, and all of a sudden you realize you want a new color and a driver’s assistance package. But this will cost you $8k more. Do you have it now?
So let's rewind and do this right.
If you want to buy a car (build a software project), that means you have a budget.
Let’s say you have $100.000 and you like Mercedes cars. At this moment, I can put on the table an offer for a Merceds-Benz - AMG G3 53 4-door Coupe that costs $99.000.
What you notice: this car has a shape, a color, wheels and the most important thing that you CAN’T notice here, a technical manual where you can find all the available features for your car. Plus designs - a lot of them.
You have this price because in this technical manual you have included the color you want and the driver's assistance package.
Just like the car buyer MUST go through the technical manual before buying, you as a product owner must go through the estimation process in order get an exact quote and avoid change requests. You should be able to drive the car, not worry about missing features.
By analyzing the technical documentation, you can prevent unknown costs and aspects that can alter your timeline.
This is where the big difference is: between having a technical documentation with designs and not having them.
For me, analyzing and estimating features starting from design has to make sense to the client. So it's important that they understand each step included in my estimation and that they understand, from the start, what each hour in the estimation is meant for.
Now let's assume that you bought the car and you decided you want to change the color. You’ll go to an authorized car paintshop. They will go through a looooong painting process that implies:
- Backing oven;
- Primer surface application;
...to name just a few.
It will take between 14 and 18 hours for the car paint guys to finish painting a single car. It took you one minute to use the color configurator, but all the next hours in the car painting process depended on that minute.
It's less time-consuming to spend an extra couple of days, analyse and make design changes at the beginning, than to make changes after you start developing the project.
Want more info about developing a mobile project? Check our piece on
What to Know before you Start
the Mobile App Development Process
2.3. Trust - Quality of the professional relationship and the project
The pricing model of a software company is based on hourly rates. They bill you according to how many hours were needed to give you the deliverables (website/app/design/etc). And because they are the specialists and you're paying for their expertise, you'll need to trust them that they're making the right tech calls in the estimation process.
Lack of trust results in miscommunication, poor technical decisions (the classic client-knows-better), and more hours you're going to be billed for.
To illustrate this impact, let’s take 50$ as an average hourly rate and a planned period of 10 working months for your project. We'd have 210 working days that are equal to 1680 working hours and you’ll need a budget of $84k.
If the estimation hasn't been done properly, you’ll 100% have a ton of change requests during the implementation. These will result in unplanned tasks, which result in delays, which result in poor professional relationship, which results in unhappy clients, which ultimately results in losing you as the client. The initial trust is gone now, because we spent more of your money on changes that could have been avoided if we had had clear specifications and design from the start.
Just like that, those 10 months from the beginning become 12 and the initial budget turns into a $100k.
|10 months||2 months||12 months|
What can you do to avoid spending that unplanned time and money? The answer is: investing enough time and effort into defining clear requirements for your product. Let me break it down once again in a table:
|Less time and effort||Enough time and effort|
|Unclear requirements||Very specific requirements that will shape your app according to your vision|
|High rate of change requests||Low rate of change requests|
|Big unplanned budget||Small unplanned budget|
|You'll be frustrated about constant delays||You’ll be happy because everything goes as planned.|
|Trouble with budget management||Control over your budget.|
In order to have a quality output of a software company's work, you need to offer them a tremendous amount of pertinent information and the more you know about your goals, vision, requirements, the more you’ll know on what to focus and make it a priority.
If you have a really complex project, you don’t want to launch it in the market after 1 year of development.
Instead, you want to work in small batches, to get feedback from real users, make user experience changes according to the feedback received and - based on this information - prioritize the development steps to make adjustments to the project.
That’s why we usually break down complex projects in multiple versions.
Instead of figuring out - after 12 months of development - that a critical feature needs to be changed and will cost you thousands, you can make what I call "cheaper mistakes", by launching the product in the market, measure the results and make the necessary adjustments to the project at the right time.
How would it be to know exactly when to do the pre-launch of your product and when actually to launch it?
By having a detailed documentation you will also have a detailed timeline. This way, you will be able to align development with the marketing and sales strategy, with your budget, and in the end you will have realistic expectations when it comes to the entire business.
It's extremely important to pay attention to this process and spend a couple of extra days with your software partner, to clarify all the important aspects of the platform and to be able to make better business decisions after you start the project.
Throughout my time as a business developer in tech, I noticed an issue: when they contact product or software companies, almost everyone wants a price and a timeline now.
However, my job is to make you understand it will take some time for me and my team to create a timeline. And for that I need your participation, so as to do a proper estimation that makes sense to you.
Estimating a project is a process of discovery, designing, planning and proposing the best solutions.
Believe me, I want to help you build your tech project.
But if I screw up the the rough estimation process and after 3 months of development on your project we figure out we'll need another 3 months to finish it, whose fault will it be?
It'll be my fault because I overpromised and underdelivered just to win you as a client. Which doesn’t work with us at Around25.
Takeaway: Estimating a software project in a very accurate manner requires a tremendous amount of time and energy because you’re trying to invent the wheel for the first time. As I said, it's a process with clear steps to follow and strong reasons behind those steps. In this way you'll prevent a lot of unknown costs and delays in your project.
3. Types of agency pricing model. Which one suits you?
As I said in the beginning, this is the information that can help you understand how a software company works and know the advantages/disadvantages of the pricing models.
At this point, it's important to realize:
- which situation you are in;
- that a long-term relationship between the provider and you is built on trust, transparency and honesty.
And this professional relationship needs to be based on a win-win relationship from which all the parties have to benefit.
3.1. 'Time and material' model
The software company is paid based on the time spent on the project. If the hourly rate is 50$/hour and a developer worked 100 hours on the project, then you will get a quote of $5000. Your project is estimated to cost that amount.
When to go for a 'time and material' price model:
- When you have unclear requirements.
- When you want to try more experiments for your startup and you don’t know which works and which doesn’t.
- When you have detailed requirements for the first sprint and not having a clear image of what’s included in the second, third, …, nth sprint.
- When you have a project where you need maintenance services.
- When you need just small changes to be made for your project.
- When the project is big and you can’t estimate how much it will take to build a complex project and the development is ongoing.
How will this work for you? If you have unclear documentation, this pricing model allows you to have change requests during the development stage. You'll pay for the time the development team spend on the project, which gives you the upper hand in case the team is efficient or you need to scale:
- If I estimate 18 hours for painting a car but I finish it in 14 hours, you’ll only pay for those 14 hours.
- If you need more men-hour in the project, the software company's developers can work more on the project and have higher income.
However, it's really simple to fall into this trap of disputing the hours your developers are spending on a task. That's why, with this pricing model, it's important to have direct access to the team, and to get daily reports from them.
In order to be a win-win relationship, you also need to consider that a software company must establish some sort of predictability. That's why you'll have to clearly communicate to your software company which is the notice period. The notice period in software development means that the client announces their software provider about changes in the team. With the 'time and material' pricing model, a notice period that is given too late results in unproductive hours and costs for the company.
3.2. Fixed price model
Being able to ask a software provider for a fixed price requires a detailed documentation, visuals and knowing all the third parties you are going to use in the project.
With this model, a software company needs to know exactly how a screen will look like and how all the information from a screen works together.
I'm going to give you an example.
The screen below reflects all the information/functionalities we implement in the dashboard section of one of our startups. Cleverwash is a marketplace where drivers can book an appointment and spend zero time in line at a car wash. Only after we built the wireframes, consulted with the carwash owners, and gathered feedback from them did we finally built the final screen for this part of the dashboard.
This is the ideal amount of detail needed for your app's documentation.
Imagine having general functionalities like: "be able to see the weather" and missing the rest of the details. Could you guess (based just on this general description) that the customer wants to display the day, hour, chances of precipitation, level of humidity, the speed of the wind and the temperature? Trust me, you can't guess.
When to go for a fixed price model.
- When you have detailed requirements and the risk of changing them frequently is low.
- When you have a project that will take 1-3 months.
The main advantages for you are that you'll have a fixed price for your project that will help you secure a budget without a lot of unknowns. Also, working with a detailed documentation reduces the risk of changing important functionalities during development.
Even if the plan looks perfect, this model has some disadvantages too. You need to be realistic about changes that will appear along the way (it happens all the time with our clients). The aim of my estimation is: no big changes and little unplanned budget.
In this situation, keeping a win-win partnership depends on discussing the aspects of running over budget and those where some re-work will need to be done.
4. Estimation process
As I said above, estimating a project is a process of discovery, designing, planning and proposing the best solutions. There isn't necessarily a right or wrong practice out there, the process can be modified based on the context.
In the following, I will tell you what are the steps I take when I make an estimation.
1. Discovery process
- Find what the client needs are.
- Find details about what the project needs to do.
- Create user personas.
- Analyse competitors.
- Search for trends in the industry.
- Start building the technical documentation.
- Define every element/feature from every screen.
- Define use cases. Understand the requirements and build the mind map.
- Mind map validation
- Build prototypes.
3. Estimating the cost of building the platform
- Estimate every part of the project separately (Web, Mobile, API) with a developer or a team.
- Review the estimation and double-check it in a meeting with other devs.
- Make final changes to the estimation.
4. Making a proposal
- Define milestones.
- Break down the budget and correlate it with every milestone.
In the end, all that matters is to be able to make better business decisions, follow a clear estimation process in order to predict as many unknown changes as you can. Whatever happens during the development phase, a good estimation will help you avoid searching in your pockets for extra budget.
If you had the patience to go through the entire article, it means you're on the right track with your next project. Feel free to share your thoughts with me via LinkedIn or in the comments below.