App Development Cost: How Much Does It Cost to Make an App?

I’ve been running a mobile and web design and development company for more than 3 years now, and – as also the lead of sales – I often hear the following question:

“I want to build Uber (or WhatsApp, Airbnb, etc), but a bit different. How much would it cost?”.

Every time I hear that question (and I’ve heard it A LOT) I feel the urge to answer:

“Considering that Uber raised $3.5 billion dollars, and at least 5% of their funds were focused on its technical infrastructure (apps, servers, websites, data centers, etc), your app should cost something around $350 million USD”.

Even though that’s the first thing that comes to my mind, I’ve never given that answer yet, because throughout the time I started to understand that people don’t actually want a number as an answer: what they do want is to understand how to build an app.

But in our capital-centric world, sometimes when we don’t even understand how to get started on learning about something new, we just try to grasp that concept with the closest notion that we do get, and that’s when the money comes in.

Do you need an estimation to build a mobile or web app?

Estimating a project is just not as easy as asking for an estimate.

There are benefits and consequences to the question which affect the fidelity of the outcome.

Deciding on which direction you go, guesstimate, or high fidelity depends on your needs and what you have (or don’t have) prepared.

See how we thoughtfully approach it in this article: How does Cheesecake Labs handle estimation for app development?

My answer to this question has evolved a lot, and today it’s basically a big bundle of new questions to better understand what that person has in mind, such as:

• “Do you already have the interface for it?”
• “Do you know which technologies would you like to use?”
• “Should we develop the back-end and be responsible for hosting it as well?”
• “Have you validated the problem and the solution before building it?”
• “Which platforms should be supported?”
• “Which code versioning server would you like to use?”
• “Are you going to organize the releases in Agile Sprints”
• And the list goes on…

In this article, we’ll talk about the main steps that we go through with our leads at Cheesecake Labs to solve these complicated questions.

So, if you have an idea and you’d like to understand how to build it (or quote it), or if you’re just interested in how many variables are involved in bootstrapping a software application product – and the business around it –  this article is for you.

Figuring out what you’re trying to do – Business and Product Validation

Since software development is not cheap – from hiring good talent, freelancers, and working with service providers – making sure you have a solid idea of what you’re building before getting started coding is a a big money saver.

Eric Ries, Steve Blank, and the Lean Startup revolutionized the way companies are bootstrapped, but one thing they didn’t take into account is how expensive software development is becoming.

That’s why having a Design Sprint with people from different areas to tighten the scope definition, creating a Lean Canvas to better understand the product, and basically creating a full Product Definition is very useful before getting started on building an MVP or starting the Scrum sprints.

If you have more questions about this topic, here’s a great article focused on better explaining Product Validation.

Breaking the long-term idea into small steps – MVPs and Agile Workflow

Another big challenge – especially for people that still aren’t familiar with agile methodologies, lean startup, and working with small and fast cycles – is defining an MVP.

Usually, those personas have a really hard time breaking down a longer-term vision of the product into smaller steps that can be easily measured and validated.

This feature break-down is essential when building software products because the concept of the functionalities tends to evolve while the project is moving forward – especially fueled by metrics that can track the user behavior and point to objective change, as an example: maybe that tiny gray button that isn’t being clicked should become bigger and brighter.

Since changing the scope – like the gray button – is something very common when building apps, having fast and short milestones is the best way to adapt the processes to evolving project scope.

That’s one of the main reasons why big companies have such a hard time building innovative apps: they are usually used to planning very long-term milestones (as in an old-school waterfall workflow), and the healthy scope changes are only detected after a long time, which makes the process – and project architecture – extremely hard to adapt, creating another obstacle for the product’s success.

Getting the interface ready – Wireframes, Mockup,s and Interface Validation

You don’t want to be a designer to think about the interface of your product. Receiving a project request with some paper drafts of how the screens should look is infinitely better than just hearing out the main ideas about those same screens.

The draft doesn’t need to look good, it’s all about understanding which elements should be there and which functionalities they should have.

Searching for UI/UX references and brainstorming which information they may contain (including its hierarchical structure) are also great ways to help the team understand what you have in mind, and also to save money by not spending so much time until everyone understands exactly what needs to be done.

Going through guidelines (like Google’s Material) and design systems (like Salesforce’s Lightning) are also great ways to validate your current ideas and double-check if the product concept is evolving into a solid and consistent experience for the user.

Deciding which technologies to use – Project Architecture, Frameworks and Libraries

For this topic, you’ll need someone you trust, or at least an organization that you trust, if you’re not familiar with the technologies that will be needed to create your idea.

Usually, when being asked which technology should be used, a developer – or a development company – will tend to suggest what they have the most experience with, and that’s a critical since that’s not necessarily the best fit for your project’s needs.

With that in mind it, having a wide – and neutral – understanding of the technologies, architecture and design patterns that could be used in the project is essential to making a good decision on which direction to follow and, consequently, which developers – or companies – to hire.

We receive lots of requests from people that choose the wrong tech stack and their product isn’t working or evolving as they were expecting.

In those cases, it’s hard to create a development strategy that doesn’t involve rewriting all the code.

Make sure your code is always versioned (it doesn’t matter which technologies you’re using), that the code is evaluated by a different person than the one that wrote it (with code reviews, for instance) and also that you always have someone you trust to give a neutral opinions on the tech stack you are using (or thinking about using).

Organizing the Schedule and Measuring Progress – Task Tracking, Crash Tracking and Analytics

Creating estimates is core when starting a software development project, but more important than creating them is keeping the tasks within the estimated timeframe.

Since it’s normal for a task to take a bit longer – or shorter – than what was estimated (since we’ve defined that the product scope is an evolving concept), the smaller the tasks, the earlier the project manager will detect any potential problem.

Since a project can have dozens of higher-level tasks, and those items can have dozens of smaller tasks in it, you can imagine that tracking the project tasks can become a pain pretty quickly.

Using a tool like Trello, Jira, Pivotal Tracker or ZenHub is a great way to keep track of everything that’s being worked on, and, together with a fast sprint, going through the tasks and making sure they are always up to date is the key to solving the task stack overflow issues.

If the project was a marathon, this workflow would be taking lots of very fast tiny steps.

Besides tracking tasks, it’s also very important to track the crashes that the application might be experiencing (this is extra-critical when dealing with mobile apps – you can find a list of them here), the update status of the system (especially when dealing with websites), with tools like Pingdom, UptimeRobot and DataDog – and the behavior of the users with Analytics like GA, Mixpanel, etc.

Releasing your product – Continuous integration, testing and deployment

When it’s time to release a product, it’s critical to make sure the process is reproducible and that it’s as less dependent on human intervention as possible.

This happens because usually, the errors will come from a person that forgot to merge a git branch or to run the tests one last time.

There are multiple applications and services that are focused on automating the deployment process, including running all the tests to make sure the robot isn’t sending something to the cloud that might be broken.

Fastlane and BuddyBuild are great solutions for automated app releases and Jenkins or CircleCI are also great options for web applications.

Launching new versions – A/B testing, data analysis, and a longer-term agile workflow

When a project is released, people tend to think that the product has reached a final state and it’s done receiving improvements, but that’s the first moment you’ll start receiving real measurable feedback from your users (if you’ve implemented the analytics from the previous item).

When a product is out there, it is time to start analyzing the usage graphs (and that’s such a fun part of the job) and trying to infer theories on why those behaviors are happening, and which changes should be implemented to improve the user experience.

It’s very common for people to plan a budget that only goes until the first release of the project, and that’s a shame since after the first release is when you’ll discover the most important things about your user, and will finally have real data to start building something unique.

A great way to do that is by having different versions of a same layout (a button that can be orange or green, for instance) and displaying one or another randomly based on each user that comes in – the so-called “A/B testing”.

Once you have multiple solutions living in parallel, you can start to compare hypotheses and have a faster evolution pace of the product, based on real feedback data.