How much will it cost to build my app?

Raise your hand if you’ve ever asked this question 👆🏾

(We can’t see you, but we felt that cool breeze from your collective hands whooshing into the air).

And chances are, if you’ve gotten estimates or are planning to, these estimates will change over the course of your project.

Why cost estimation is hard

Similar to estimating how long it will take to build something, estimating how much it will cost to build something is a best-guess game, and the biggest challenge that technology teams face when developing a project is when clients and stakeholders latch onto cost estimates as unchanging truth vs your team’s best-guess.

And there are a few reasons estimates are hard to get right:

Unexpected roadblocks often arise

Custom software development is a research and development process. Sure, the engineers you’re working with may have built something similar before, but now they’re applying it to your use case for the first time, and there are unknown unknowns to be discovered along the way. There is always a bit of uncertainty in every estimation. When we estimate projects, we use an “uncertainty multiplier” that shows the span of what a project “could cost,” often doubling the potential cost of a project. Just yesterday our most senior engineer got stuck on an issue for ~3 hours unexpectedly. It was something they had done many times before, but the app was just different enough that it took additional time to get it working properly. So when someone says, "I need it all done for a fixed price,” they are forcing all the risk of those uncertain issues on the engineer.

Roadmaps will change as you get user feedback

If you go into a project expecting the get feedback that directs your future development [i.e. agile development (and our way of working)], then estimating the cost of that future development is dangerous. Why dangerous? Because you might cling onto your original estimates with less flexibility to react to your user needs. You can spend weeks drilling down an estimate for a complete 8-month project that needs to change course within a month of beginning. We don’t typically even provide estimates past 3 months - this is why.

You change your mind

Plans can change the more you think about and actually work on something. It often happens that once you’ve built what you designed and you can “put your hands on it,” you realize that your design or assumptions were flawed in some way you couldn’t see before. We have clients change their minds all the time but expect the budget to stay the same. You want your technical team to be flexible and responsive to changes like this, so holding your costs with the same flexibility you expect from your team is important.

Why projects are expensive

It takes time and resources to create something from nothing, and in addition to the human resources you’re paying for, there are two additional factors that affect the time and cost of your product:

Scope

This relates to how many things you are building. To keep costs low and focus on iterative development, you should focus on one user outcome at a time. But often, founders come with a long list of features they need an app to do. The problem with a hit-list of features is that features don’t tell us what the users need to accomplish, and by compiling a long list you’re presupposing you know what the user needs before asking them. This could lead you to build things (paying in time, money, and/or resources) that users don’t actually want or need. It’s the reason why we encourage focusing on one user outcome at a time, testing that with users (making sure they like the direction you’re going), and proceeding in the right direction with integrated feedback.

Fidelity

This relates to how perfectly a feature needs to function. For example, you could spend a weekend building a search bar or you could spend billions of dollars to build a search bar, as Google has. Fidelity begs the question of how well features ought to function before you can begin testing them on users. We often run into founders who think features have to be absolutely perfect before they can release them to their audiences, but by releasing earlier you can learn what your users think “perfect” would mean versus you guessing for them. The founder of LinkedIn, Reid Hoffman, famously quoted, “If you are not embarrassed by the first version of your product, you've launched too late.”

As you can imagine, the bigger scope and the higher fidelity, the more your costs will rise.

A better and best way to think about your tech budget

So, we haven’t gotten you any closer to knowing how much it will cost to build your app.

And, as you can imagine, it depends.

It depends on how long you stay in business.

Because once you build an app or a software product, you will always have ongoing work to do.

Between building or changing features based on user feedback, updating dependencies, and keeping up with the market, you will always be developing your product.

So, if you plan on staying in business and having this product as a core function of that business, you will always be putting money towards your product. Therefore, there are more appropriate ways to be thinking about your development budget:

Better

Think towards your next milestone.

Your tech is never finished, but you can likely visualize the next milestone you’d like your product to reach. If you need solid numbers, ask your team to help you understand what it would take to reach that next milestone. Bear in mind, that there will still be work to do after this milestone, but this reframing is especially helpful if you’re working with investor runway or if you need to take numbers to an investor to fundraise.

Best

Think towards a monthly budget.

Don’t think of your product/tech as a fixed cost, think of it as an ongoing line item. What is your monthly budget and how much of that can you afford to put towards your product development on a recurring basis? So rather than thinking “how much will this cost to build,” think about what percentage of your cash you can invest into tech and plan to invest that on a monthly basis. What your technical team can help you determine with that monthly budget is what kind of development velocity you can expect given your resources.

We know we live in a world that needs estimations, but the more founders understand the challenge their technical team assumes with project uncertainty and flexibility, the better partner a founder can be when the inevitable estimate changes arise.

Thinking about your technology as a monthly spend (vs a one-off cost) will help align your technical team to your ongoing product process.

Your tech, like your company, is never done; treat your budget accordingly.

---

ThinkNimble turns clients into confident tech leaders who understand their customers and build better solutions. If you want to understand how technology can increase your bottom line, let’s chat.