When people want to build software…
From time to time I receive emails from potential clients or I see discussions on different groups for people looking for developers.
“I want to build an app similar to UBER, can you please give me some rough estimation”.
“Hi, I am sending you a BRIEF for my app, there is a list of functionalities and tech requirements, please send me an estimation ASAP”.
“Dear Desmart. I would love to build an educational application. It’s an app for kids, they can play around with colours and shapes. I attached a couple of screens and a short description of the app”.
In such cases, estimation seems like an easy task. But why it’s not so clear to us? Why most software houses don’t like such emails? How can we improve the process of estimation to make it more transparent and more reliable?
The truth is that very often clients forget about one important thing. The Software they want is not a product, it’s a service. At the end of the day, you don’t pay for a product, you pay for working hours of developers (to build and maintain the software). In many cases, clients also don’t really know what would the final product look like. They have some vision, they have the money, but when it comes to details, they just get lost and they still expect that software developers will know what and how to build for their startup.
Of course, people want to know the final price and we understand that. When I order a dedicated cake from the bakery I also want to estimate my budget for that. Of course, the baker has done hundreds of such cakes before. With software, it’s not the same thing. Complexity is much higher.
Clients can use online estimators, but quite often they can get surprised that a “simple” app can cost so much money. “I asked for a simple app like Instagram – it can’t cost that much” – they say. Most of the people have never done software before, so they are not aware of how much money and a time it takes to create online stuff.
Bob the Builder
In my opinion crafting software is like building a house. Imagine, that someone comes to you and says: “Hey, I want to have a house like my neighbour’s – how much will it cost?” You look at the house next door or the picture and it’s really hard to say how much will all materials cost and how much time it will take to build such a thing. There are too many unknown issues like: the size of each room, the materials used, a colour of the floor and so on. Without a clear plan and guidelines, you will never get a proper estimation. It’s just a wild guess.
Unfortunately, sometimes the client is stubborn and he wants to have a fixed price anyway (without answering many relevant questions). He sends a general request to many developers asking for an estimation and then he tries to compare a couple of options. But wait. What is he comparing actually? Probably a few estimations (wild guesses) of companies who want to win the project and will bet on the price.
What might happen next?
OK, let’s assume, developers agree on a fixed price. They build something without a proper plan and without any blueprints. Because they didn’t prepare, initially the client might get something not well estimated.
Results?
- The client doesn’t get what he expected
- The team works more than expected
- The client has no money for further development and changes and oftentimes he needs to start again
- The client is pissed off
The challenge with fixed estimation.
When the client requires fixed price as an estimation, most of the people he employs will overestimate his project. Why? Developers take into account the risk of delays, some unexpected work and they assume that the client will change his mind during the development process a couple of times (it happens in 99% of all projects). They are not a charity, so they won’t be working for lower fees. They need to cover that risk by a higher margin.
I have friends in the real estate industry. They say that prices of the apartments can be doubled comparing to the first estimation, to cover the unexpected issues, risk and margins.
Why do clients like fixed price estimations?
They think it will be cheaper and they can have a fixed budget for the project. They feel secure with a total price on the agreement. It makes sense, but the real question is: can we have something better than a fixed price – more effective, more flexible and efficient?
OK, but how does it relate to the IT world?
It does. More than you think. If you just have a general overview of what to build, almost no one wants to give you a precise estimation. They will be overestimating or charging extra at the end of the development, because software developers need to take into account all of the aspects mentioned above (the risk, the delays, client’s changes etc).
The second important issue is that a general overview might lead to unexpected results. Unwanted functionalities, huge combos without any clear purpose. Sometimes you need to accept failure, instead of saying “this one more feature (no. 123) will be the killer feature and will do the business”. In 99% of cases, it won’t.
What would MacGyver do?
In software development, you need to start with a simple plan and go into details every week. Build an MVP first – the simplest version of your product, which you can deliver to the market.
Remember this – from time to time your imagination goes far beyond what’s possible. At Desmart during the first stage, we talk to the client and see what his experience with software development is and what is his vision of success. We don’t just want to build some online product. We want to help people to be successful and earn money to expand in the future.
We need to talk!
Yes, our developers talk. A lot. They need to understand how your product will work, they help to write user stories to see what functionalities they need to create. They ask about many issues and you will be surprised how many unanswered questions you will have after such session.
We try to estimate projects in 2 phases:
I – Analysing and Prototyping
Here we sit together and talk a lot. We analyze clients need and we help to prepare user stories. We write the definition of DONE and we make sure that the client has accepted created user stories, so we can start development.
II – Development in Agile
This part will be described in my next post. I will point out, what makes the final price different from the estimation at the beginning and how the process of Agile might change the budget
Why don’t we start coding instead of talking?
This approach is wrong. Don’t build without knowing WHAT, WHY and HOW to build your product. Confront your idea with our software experts – ask them questions, argue with them, tell them about your needs. You are the business guy, but they are your tech partners.
At Desmart, we prepare technical and business analysis, which covers all the important issues like tech requirements, the client’s expectations, MVP and further functionalities that we might consider on the way. We include some business assumptions to make software with the aim to achieve tangible goals. During this stage, we need an analyst on our side and he spends a few days to prepare such a document with the client. With user stories, we clearly define what the user will be able to do with the application and how it relates to the development process. User stories relate to the need of the Product Owner (client), stakeholders (user) and the team (folks at Desmart).
When user stories are accepted, the UX Designer start working on a prototype. It might take a few weeks before it will be done. It requires a close cooperation with the client on a daily basis. He becomes a part of the process. It’s really important. The UX Designer can’t guess. He can give a piece of advice, but the client takes ownership and final responsibility for the project. The prototype is a flexible visual version of the product. As a result, they create a clickable version of the project together – see example below:
If you are not familiar with wireframing, just find an experienced person and spend a few days with him and prepare such a thing. Remember – it will change the way in most cases. We love prototyping and we push our clients to do so. That’s why a couple of years ago, we’ve created JustProto, which now is UXPin. We use it on a daily basis with clients and it works brilliantly.
Additionally, we will write down every aspect of the app and all the things that need to be done on the backend (server) side. As a result, we will help a client create a Backlog. This will be a base for the second stage – Agile Development.
Why it is so important to have a Prototype and a Backlog?
Because your idea and vision might differ completely from the things you will be able to build. After a discussion with the analyst and the UX Designer, you can realise that your app is not as “simple” as you thought at the beginning. You see hundreds of integrations and tech issues, you haven’t seen at the stage of coming up with your idea.
With prototyping, you can see the bottleneck and ask thousands of question without any line of code written yet. It’s your map, a guideline. It gives you the flexibility to change some features and visuals very quickly. No developers needed! You work only with the UX designer and as a result you receive a clickable version of your software. Again, no line of code is written yet and you can see what you will get and moreover, you can better understand your product and all the requirements. Awareness and understanding of your project is the key in software development.
OK, we have this plan and a prototype. Can you estimate now?
Yes, we can, but it’s not the final price. Backlog and prototype serve to the client as a starting point. That’s not the final version of the project. In 99%, will differ at the end. That’s why you need Agile approach in the development phase. What is the most important here, that everyone understand his role in the project and people are willing to communicate properly and move things forward.
Knowing what to build, how the software will look like and after defining user interactions, we can prepare a basic estimation for you now. We create a special team for your mission and give you an overview of how many Sprints (weekly periods of development) the process will take. Let’s see an example of estimation in Agile:
Assuming that you need such a team:
- PHP developer (senior) – 100%
- PHP developer (medium) – 100%
- Front-End developer – 70%
- Tester – 50%
- UX designer – 30%-50%
- Project Manager – 10%
you will pay X EUR / week.
The project will take around 10 weeks (sprints) to deliver the software. It might be adjusted if you change your mind during the development process and if you want to create an additional functionality – we need to be flexible here.
As you can see, this is one of many ways you can answer the question: “How much for an app?”. It’s transparent, visible and you can finally move forward, being aware of the job that needs to be done. For some of you, it might look like a waterfall approach, but the client needs to have some budget defined at the beginning, because it’s hard for him to start without understanding what he will pay for.
Having fixed budget, we can clearly define the project time (determined by the quantity of Sprints) and allow a flexible scope of the project. The flexible scope of the project means that we can deliver within the specified time as much as possible required by the client. Sometimes it does not mean that will do all of the functionality on the customer list, but we will do the most needed in best as possible way.
What happens next?
With such an analysis and prototype, you are well prepared to ask for an estimation. Developers will love you for the prototype and the backlog. The question you might ask is: “Is this a final price?” Of course not. This is just a base. It’s still based on many assumptions, guesses and wishes. Many issues might change during the development process and you need to be flexible here. How to deal with that during the development process? Next week I will write a story of, how we do it at Desmart with some clients and why the most important part od development is not the budget, but the team, communication and clear, transparent process.
If you stay with us, we start developing in Agile which is the best process created in software development. WHY? I leave the answer for my next article, where I will describe in detail how we create the software step-by-step with the client and what are the pros and cons of such an approach.
Would youl like to get a free estimation of your software project?
Just contact us.
Ypou can also read this article and get to to know more konwledge about app cost estimation? Just read this article.
