What you need to know before building an app

Design first

I often get asked what it would take to build an app. Websites like http://howmuchtomakeanapp.com/ give a pretty decent estimate of the overall cost, but their estimates are only really relevant once you know exactly what your app needs to do.

The story usually goes like this:

Joe Shmo (or Jane Shmane) thinks of something in their life that would be improved by having an app that could help them. They think through the idea a little, working out what features would be awesome if the app could do and then say “OK, now what will it take to do this?”

The two biggest pieces of advice that I give to potential app builders are:

  1. Figure out what the absolute minimum set of features that your app needs to be a Minimal Desireable Product.
  2. Find a UX designer to make sure that the app that you build is going to be intuitive and easy to use before you write ANY code.

There are many hacks you can do for broader market validation of your app concept (like make a landing page for you app and buy some ads to gauge interest). You want to make sure that you have an app concept that can really appeal to a lot of people. But it’s not really a way to figure out what features are your bread and butter. Once you’ve decided out that there really is a market for your app and that your app concept really provides value (and isn’t just “Instagram with an extra filter”) you have to figure out what exactly your app does.

1. Figuring out your MDP

Your MDP must be the absolute minimum. But it also needs to be something people want to use.

When Jane thought of her app idea, her mind started racing with all the possibilities that this new app could do. Each new feature was better than the last.

But building an app that does everything will not only take too long and cost too much money. It will also end up being confusing to use and will end up having many features that most people don’t use.

If you can come up with an idea for an app that does its job well, you’ll have people actually using it. And if you listen to those people and ask them for feedback, future app updates can include the features that are most important to them.

Let’s look at some examples.

Someone came to me recently with an idea for a job search app, trying to figure out how much it would cost to have their app idea built by a dev shop. But they hadn’t yet thought through whether or not their app needed LinkedIn authentication. This is something which might be a good thing for a job searching app, but may or may not be necessary, depending on how the app creates and populates its user profiles. (This also means that they hadn’t fully thought through what information would be included in their user profiles and what information would be necessary for their app to work well.)

Another person had an idea for an app that would help them keep in touch with their friends, family and business acquaintances during their commute. But they hadn’t thought about whether this app needed to have built in voice recognition on the initial release or if it could work well enough without that as long as they had a good, safe, car-friendly interface.

How to figure out your MDP

Trying to figure out what features you really need in your app is tricky, but there are a few things you can do to help with the process.

The first thing I always do is ask myself what features I personally would want to use on a frequent basis. If I wouldn’t want to use the app without a particular feature – it’s probably a must.

The next step is doing some research. Find some friends who you think would want to use the app, pitch them on the general idea and see what feature ideas they come up with. If a few people say the same thing – it’s probably a must.


After asking your friends, find some strangers to ask. Don’t be afraid of them stealing your idea. Getting feedback from people outside of your own bubble will help ensure that your MDP is desirable to a broader group of people.

2. Design first. Code second.

So Joe took my advice and really thought through all the features he needs in his curated news feed app. He wrote them out, and went to his dev team for an estimate about how long each feature would take to build.

  • User Login
    • 3 days
  • User Profiles
    • 4 days
  • News Feed
    • About a week
  • Settings page
    • About a day or 2
  • Onboarding
  • Oh, I forgot about that – I guess a day or two to code it up?

In my experience, the biggest cost in app development is taking that initial idea, getting it built, and then realizing that the app “doesn’t feel right”. It’s either missing some important feature(s), hard to figure out how to use, or doesn’t show immediate value.And once you’ve spent time and money getting the app built and it’s not right, fixing it is often just as costly as building the app from scratch. You’re going to end up having a few versions of the app anyway, as you get user feedback and make changes. If you use up all of your restarts because you didn’t think through the user experience up front, it’s going to be tough.

mario dying

Doing your best up front to make sure that the app is intuitive and can actually do everything that it needs to do easily is probably the most important thing you can do to keep the costs of app development down.

You’re still going to end up having revisions and changes – that’s unavoidable. But if the overall flow works the changes should be relatively minor and shouldn’t break the bank.

We’re here to help

If you are working through an app idea, we’d love to help you work through any gotchas in your design and development. Send an email to help@getwombat.com and we’d be happy to set up some time to help you out.


If you’ve gone through the app development process and have a designer or developer you would like to suggest (personal experience only, please), feel free to tell us about them. We’d love to highlight them on our blog.

One thought on “What you need to know before building an app

Leave a Reply

Your email address will not be published. Required fields are marked *