Just kidding – but it as well can be around that sum. The most important thing to start with is that you can never predict and estimate the cost of every tiny detail of the product development process. But you can try to get as close as possible.
So you want to create a web app. Maybe you already have a marketing strategy for the promotion. Or maybe all you have is an initial idea. Regardless of how much you think you know about your app, you need to (1) discuss it with the team, (2) clearly set the task, and (3) estimate costs.
Web app development costs are a thorny issue, because clients instantly want to hear an accurate figure, and companies try to explain why it doesn’t work like that. Both sides insist they are right.
In this article, I will explain why cost estimation isn’t that simple, how to make it easier, and how we estimate web app development costs.
What does web app pricing include?
When I say web app development, I don’t mean just coding. I’m talking about products here. App development includes several types of engineers, testing, analyzing, design, and managing the process. So I want you to clearly differentiate between product development and writing a piece of code.
Now that you know the real idea behind this article, I want to dig into it. Why should web cost estimates cover not only coding, but also other areas of product development? I see four main reasons:
Budget planning. Apart from development, you will need to test your app, analyze it and be ready to launch a solid marketing campaign. Plus, there are always different sorts of cost contingencies.
Assessing the idea’s viability. What might seem a simple idea can ultimately involve complex development solutions. Or maybe there are lots of apps like yours, so you’ll need to think of a creative way to make it profitable. And when you know the approximate amount, you should answer one simple question: can you even afford it?
Pitching ideas to investors. When you talk to them – and you will talk to them – forget about words like game-changing application and huge market opportunities. Nobody’s interested in your unique concept unless it can generate a profit. What you need is the expected revenues and costs of your web app, supported by realistic and detailed assumptions and projections.
Unique products result from teamwork. Quality applications are possible because of close collaboration among team members, with each expert being able to contribute to building an efficient app. Communication is as important as development skills and management.
If you try to Google how much some web apps cost, you won’t find a thing. Here’s why: it’s difficult to figure out what point of development we can regard as the final one. Most consider the web app done when it’s deployed to production. However, as soon as you go live, you will think of a new feature you want to add.
You probably wish there was a Magic 8-Ball that could answer the question: ‘How much money do I need to make a web app?’ but, alas. And I also know how tempting it is to skip the calculations and all the questions and start the fun part – developing. But this is a big no-no, because you are likely to end up at the stage of “Wow, that’s a great idea!”. I’m writing to help you move beyond that stage and achieve decent results.
Web Application Cost: Domains of Knowledge
There are a few things you need to know before estimating a web app cost. In this part, I’m going to tell you a common approach to describing an idea to developers, and explain situations when it works and when it doesn’t. Most importantly, I will reveal how to make sure your estimates account for things you might not know about your future app.
Approach 1 – Thinking about the end product
The most common approach to estimating a web app is to visualize the end result and trace the steps backwards to the current position of a project. The question to ask is: What do we need to do to achieve this? Usually this approach doesn’t work for novel ideas, because there’s too much uncertainty about the end product.
Take Slack, for instance. It seems like an ordinary corporate messenger, and the end result might have been described as I want a messenger like WhatsApp, but for corporate use. It’s a good definition for end-users, but not for people who create apps. Why, you ask? Because it’s incomplete, and Slack isn’t WhatsApp. Think about the Slack case: What makes it unique? What problems does it solve? You need to be specific about these things so engineers will know the technologies they’re going to use to build the product. Also, marketers and product owners should know your audience and competitors, and designers need to know your vision before starting the first mock-up, and so on. Only in this way, is it possible to count the degree of effort the team will put into creating the app. You see my point?
I definitely know what the end product must be. What should I do?
Most experts I talked to before writing this article suggest treating the app like an experiment. It means formulating a hypothesis and describing what we think will work best. And also being ready to change the course of development as you learn and try new stuff. In practice, it means adding or removing some functionality to make the rest of the app work properly until you find a happy medium.
Somebody wants to build a social network for ravers who want to find fellow music lovers to go to parties together. The initial idea might be to build an ordinary Create an account login system. However, how do you make users believe the people in the app are real? You don’t allow them to create a rave account, only log in via Facebook. That’s the kind of change I was talking about. Rule of thumb: deviation from the original idea is 99% inevitable.
How to calculate costs in this approach
The calculation is pretty rough in this scenario. You can use Order of Magnitude Estimates.
It will be like this: “I’m 90% certain that the app can be completed in between 50 and 95 days. I’m also 80% certain that the project will cost between $50,000 and $80,000.”
Here’s another approach which I don’t want you to use:
Approach 2 – Imitating another app
Dude, let’s build Trello, but with video charts. This, and a thousand of other ideas try to imitate an existing app with a slight change of functionality. The illusion makes us believe that we already know what to do, but no – it doesn’t work like that. Even if you do build a video charts-based Trello, it will be nothing like the original one. I mean the code and functionality.
This approach is a big no-no, because most likely the app will be far more complex than it seems. It’s hard to predict what elements the app will consist of, so the technology you’re going to use will be equally unclear.
How to manage things we know and don’t know
Why do I keep saying that we don’t know something? Because technologies are changing too rapidly, thus we have uncertainty. Novelty of ideas goes hand-in-hand with uncertainty. Although the founders may have a clear vision of the idea, chances are they are understating how possible it is to achieve it in every detail (otherwise, the idea is not that novel).
How to tackle uncertainty, then? Try to imagine a scale from I don’t know this to I definitely know this. Divide it into three sections, and you will get these categories:
- Known Knowns. This is something we have done before, so we know how to deal with it. Estimates in this category are mostly accurate because of the previous experience.
Example: We will need two back-end engineers and five weeks for this task. They have done something similar, and they know what to do.
- Known Unknowns. This is something we know that we don’t know. This category includes risks and unanswered questions. Before estimating this part, we need to research and investigate similar cases. Estimates in this category range from the worst-case scenario to the best one.
Example: We need to achieve a certain level of server response, but it’s hard to predict the load right now. Which framework is best suited for this use case? Let’s think…
- Unknown Unknowns. This is something we don’t know that we don’t know. No estimates can be made here because…well…we just don’t know what to estimate. However, we can’t totally eliminate uncertainty, but we can reduce it.
Example: ?????? Ohhhhh, sh💩t, this thing doesn’t work. Who could have known this?
Our approach to estimating web app cost
There’s no secret formula for calculating web app costs, so we at Django Stars take multiple steps to estimate web app pricing.
Step 1. Create user stories and engineering tasks
We collect all our Known Knowns and the rest, then use them to develop possible user journeys. User story mapping focuses on users’ needs and wants, and allows our engineers to make first assumptions regarding the technologies required to implement these ideas.
Step 2. Clarify the scope
Making first assumptions is not enough to start working, though. Each team member needs to know their task, and your view of the app. The scope of work varies considerably among different roles in web application development, based on the complexity of the desired web app.
Depending on the task, the team members may ask something like this:
This table shows just some of the experts required to create a web app. For most cases, you are likely to need more – a graphic designer, QA engineer, project manager, copywriter, etc.
Step 3. Estimate each task
When we have divided the scope into smaller tasks for each role in the team, we use a Three-Point Estimation Technique. This approach allows us to estimate the most optimistic, most likely, and pessimistic time for development so we can know approximately how much time it will take us in total.
Now I will provide a real example so that you don’t get confused by formulas. When you see how it applies in real life, everything will become clearer.
An example: Say, you want an online ordering system for burger delivery. We know that for such a project, the user will need to (1) log in, (2) navigate through the menu, and (3) checkout the cart.
To implement each feature, we will need this many days:
There’s also such a thing as Standard Deviation. Here’s how it’s calculated:
We at Django Stars take a 95% confidence interval. So, the final formula will be like this:
So, to implement the most fun feature – Cart checkout, we will need 10 ± 3 days. Notice that different features have different risk levels associated with them (measured by the distance between three estimates). There is more risky tasks as well as less risky ones. If you see a risky feature with big difference between three estimate points it’s good to ask the team “how can we reduce the risk?”. Maybe we’ll need an additional investigation, or try to limit the feature scope, or we won’t need the flexibility that we thought we needed. It’s a starting point for discussion.
Now try to calculate how much it will take to develop Log In and Navigation menu. You will see that it’s not really that difficult.
And another important thing…
As you can understand, this is a pretty rough calculation, because other factors may either speed up the web app development or block it. Remember the most important ones:
Communication. Web app development is impossible without you communicating with developers, designers, the product owner and the rest of the crew. Your primary task is to explain exactly what you want. Unless the team understands the goal, there will be lots of confusion.
Creative process. All the ideas we come up with result from a brainstorming session. Creativity applies to design, development, marketing – to everything.
Additional tasks. During the development process, some unpredictable issues or tasks may arise that team the must implement so the app works correctly. Some of the additional tasks may require particular team members to engage more, thus more development time.
What to do if you don’t agree with the web application cost?
If the development cost looks too cheap, don’t hesitate to ask what the price includes, how many team members are involved, and if everybody understands the scope correctly.
A low price can be appealing, but don’t fall into the trap of being forced to pay again and again for further bug fixes and improvements.
If the cost is too high but you want to work with the team, there are two things you can do to reduce it:
Cut the scope. Include only the essential parts of product development required to create a minimum viable product (MVP).
Find alternatives. Some highly estimated items may have cheaper substitutes. Quite often such changes don’t affect the end product, but rather change the way the application functions and the services it provides.
If time happens to be your priority and you want to accelerate the process, you need to (1) stay calm, (2) consider every step, and (3) be ready to pay a bit more than you expected.
Web app cost estimation is conducted by business analysts, product owners, and developers. Together, they can tell you how much it costs to build a web app. This process is not a one-day job and requires your active participation to make the estimates more accurate.
Once you’ve explained your idea, the team will divide all the information into three categories:
- Known knowns. What we know and most likely have done before.
- Known unknowns. Something we know we haven’t done before, so we will need to think about it.
- Unknown unknowns. Something unpredictable that we have a vague feeling about.
This will help the team understand and calculate the risks during the development process.
Django Stars uses the three-point estimation technique to estimate how much a web app will cost to create. This includes not only the code writing, but the creation of a complete product.
It’s important that you always keep in mind that apart from the technical side, there’s communication and a creative process. These factors may slow the process if not taken into account; but they can boost it, if they are treated properly.
The main rule: don’t rush, and be careful with your wants. Creating a web app is not about developing a website, but rather a whole system. In such cases, estimation is more or less accurate. So just relax, talk to the team, and enjoy the development process.