How Much Does It Cost to Make an App?

You’ve got a great idea for the next big thing in apps, and now you’re wondering: how much does it cost to make an app?

The good news is that there’s no standard pricing. App developers charge whatever they want.

The bad news is that there’s no standard pricing. App developers charge whatever they want.

[tweet_box design=”default” float=”none”]The good news and the bad news: there’s no standard pricing in app development.[/tweet_box]

So, Approximately How Much Does It Cost to Make an App?

There’s not a simple answer to that question because price isn’t necessarily a primary factor when choosing a developer. Sure, it’s important – it’s just not the most important thing.

Pricing varies widely from dev to dev, and the idea that US-based developers are far more expensive than those overseas doesn’t necessarily hold true, either.

Check this out:

This document shows app development quotes from 97 different agencies and freelancers that received the same email asking for project estimates.

Download a .PDF version of this information here: App Developer Quotes

For the same project, app development quotes range from $1,000 to $250,000, and project completion dates are expected to take somewhere between 10 days and a year.

The (mathematically) average price for the project comes out to $19,588 – but obviously, the “average” price is rather misleading when you look at that overall range. So, what if we look at the distribution to see which price quotes are most common?

Now we can see that more than half of the prices quoted are under $10,000, and only a few developers quoted anything over $50,000. Still, the data doesn’t really tell us anything about the actual work these developers produce, nor does it indicate the developer’s level of success.

So, how much does app development cost?

It really depends on how much you want to spend.

[tweet_box design=”default” float=”none”]In app development, price is important. It’s just not the MOST important thing.[/tweet_box]

Before You Shop Around

Here’s the most important takeaway from all that information:

When it comes to shopping for a dev, if you know what you want to accomplish and you’re willing to shop around, you’re very likely to find a developer that will build your app within your budget.

That means that step 1 is knowing what you want to accomplish.

You don’t necessarily need to have any technical knowledge to get an app built for you, but you should know exactly what you want your app to do.

Before you start shopping around, make sure you’ve got a clear and specific idea of how you want your app to function, and be ready to answer questions. If you can’t describe it, a developer can’t build it to your specifications, so think it through.

Remember, too, that quotes aren’t 100% accurate. That’s especially true if you’re not clear on your scope and requirements. There are just too many variables when it comes to the actual build, and in most cases, you’ll want to adjust and make changes when you have new ideas.

The more clear your original specifications, the more accurate your timeframe and price quotes will be.

[tweet_box design=”default” float=”none”]You don’t need tech knowledge to get an app built, but you must know what you want your app to do.[/tweet_box]

To help you communicate your idea to the application developer, you might want to write out a list of functionalities your app will need. For example, if you need users to be able to send you messages, upload documents, or save their progress, be clear about that from the beginning.

Some people draw or map out their app process, and if you can do that, it’s very valuable.

Your developer should also know why you want this application.

What problem does it solve?

What do you intend to achieve from it?

With his or her greater experience and technical knowhow, your developer may suggest more efficient and cost effective solutions. Plus, they can point out potential pitfalls in your current app plan that may prevent you from reaching your ultimate goal.

In the vast majority of cases, there is going to be some discrepancy between what you’re asking for, and what your developer thinks you’re asking for. These situations become apparent during the build process.

As things start to come together, you’ll realize that what the developer is building isn’t exactly what you envisioned, and adjustments will need to be made. It’s a normal part of development, but it can also cause major problems if the rift in understanding is large enough. Lots of communication at the outset helps both you and your developer stay on the right track.

Once you’re ready to start shopping for an app developer, these are some of the things you should be looking for:

Evaluating & Choosing an App Developer

Evaluating The Quote

In a vast majority of cases, a developer that doesn’t ask you any questions before sending you a quote is probably not the best choice.

For a person or company to do a great job that meets your specific project’s needs, they should communicate with you and get a clear idea of your expectations and goals first.

There are some situations where an app developer may send you a quick preliminary estimate if you ask for it. It’s in your best interest, though, to invite more communication at the outset so that your quote more accurately reflects the work that will actually be necessary.

[tweet_box design=”default” float=”none”]A developer that doesn’t ask any questions is probably not the best choice.[/tweet_box]

If you’re serious about your application project, one of the smartest things you can do is to pay a developer for a few hours of work so that they can research your project and come up with a clear framework and proposal.

For that initial investment, the developer is laying the groundwork for a solid project.

They’ll take the time to figure out what you want to accomplish and how it’s best completed, and even if you ultimately decide to use a different person or company, that consultation can be crucial for helping you define your project’s scope and potential.

Plus, you’re not obligated to continue working with that developer once they’ve laid out that framework. You’ve paid them for the work they did, and now you have something that you can take to other companies to help communicate your requirements.

Whether you pay for those initial development hours or not, though, your quote should reflect at least some communication with the developer to ensure you’re getting as close to an accurate figure as possible and to avoid major problems during the build. If you get a quote for what the developer thinks you want, and it turns out that you wanted something entirely different, that’s a recipe for conflict and financial disaster.

Verbal agreements are never a good idea.

Make sure that the scope of your project is spelled out in writing, and that it’s described in clear, unambiguous terms. Some projects take months to complete, and a few weeks in, nobody will remember exactly what was said.

Ask your developer how they break down their quote, too.

Sometimes, the developer bills based on the number of hours they expect to spend on your project. If this is the case, ask how they determined the amount of time they’d spend, and what happens if they come over or under that estimate. It’s almost certain that their estimate is going to be off by at least a little bit, even in the case of experienced developers.

Other developers charge a flat fee for the project. Again, ask how they came up with their quote, and determine what happens if the scope of the project changes.

There is a third billing model, and it’s unpopular for a reason. In lieu of billing for the build, and often without any upfront costs, some application developers will build your app and charge you a monthly fee to use it. It’s similar to a lease, and that means that you don’t actually own the app. There’s a lot of potential for problems in situations like these, and in general, we don’t recommend that you enter into any arrangements in which you don’t own your app and the code that built it.

However, you might want to keep your developer on a retainer.

We’ll go into more detail about this later. For now, understand that you’re probably going to have ongoing development needs as mobile platforms update, you need additional features or security patches, or you embark on related projects. Keeping a good developer on retainer is often well worth it.

[tweet_box design=”default” float=”none”]If you get a quote only for what the developer THINKS you want, you’re setting yourself up for a problem.[/tweet_box]

Scope Changes

Inevitably, as your app build progresses, there are going to be times when you want or need to make changes.

Sometimes, this is because of a misunderstanding about the nature of the project, but with good developers, by far the most common changes in scope happen when you see your app coming together and you’re inspired to add additional functionalities.

When you got your quote, you should have asked about the way your developer handles changes that take more time.

From a business perspective, it’s wise to budget for contingencies so that you have the means to complete your project the way you want it. If you’re on a tight budget, be sure that your app is well planned from the start, and consider asking your developer if additional features can be added later.

Keep in mind, too, that it’s very difficult for you to tell the difference between a “small change” and a lot of extra hours of work.

For example, imagine you’re in the middle of the build and you decide you’d like to add a button to one screen. Even though it seems like a tiny thing – just one button – that “tiny” change might affect a lot of other functionalities, and your developer may need an extra 3 hours just to create that one little button.

Occasionally, you might ask for a functionality or feature in the middle of a build, and your developer will tell you that it simply won’t work with your app.

If this happens to you, it’s not because your developer is trying to avoid the extra work – it’s because he or she built a foundation for one thing, and they can’t make the change on that foundation.

Think of it this way:

What if you wanted to put a pool on the roof of your house?

You have examples, so you know it can be done. There are houses with pools on the roof.

Of course, those houses have thick, heavy roofs, which are supported by reinforced walls, which are built on a foundation that is specifically designed to hold the weight of reinforced walls, thick roofs, and pool water. If your house doesn’t already have the foundation, walls, and roof to support a pool…you’re not going to be able to put a pool on the roof.

[tweet_box design=”default” float=”none”]In app development, changes are inevitable. How do you handle them?[/tweet_box]

Accessibility

Obviously, communication is a major component of your app build.

Before you even ask how much app development costs, you should have had at least one conversations about your vision. Then, when you get the quote, there’s even more discussion ahead.

It makes sense, then, that your developer should continue to be communicative throughout the build.

Effective communication is as much your responsibility as theirs, and basic courtesy goes a long way. You have obligations and responsibilities outside of this project, and so does your developer. Plus, they’re probably working on multiple projects, so it’s unreasonable to expect them to answer every phone call, text, or email immediately.

Prompt and open communication is a reasonable expectation, even if constant communication may be a little too much to ask.

A developer that’s difficult to reach or understand during the quote process is likely to be even more difficult to reach while your project is underway.

While a reasonable amount of contact is necessary to ensure that you and your developer are in agreement on your project requirements and execution, your preference also plays a part. If you know you want frequent check-ins, want to be able to ask specific and general questions on a regular basis, or you want to have an inside view of the development process, tell your developer at the outset.

[tweet_box design=”default” float=”none”]Effective communication is as much your responsibility as your developer’s.[/tweet_box]

Answering your messages and calls takes time. That’s time that your developer could be spending on a build, so it’s sensible for them to charge you for the time they spend in communication.

Make the most out of every contact with your dev.

Instead of sending one-off questions and comments every time you have a thought, jot down your ideas and minor concerns to send at the end of the week.

If you’re the type of person that wants lots of contact, ask your developer to schedule a weekly phone call at a regular time, and they’ll include that expectation in your project scope.

Remember, too, that the longer you take to respond to your developer’s questions and requests, the longer it will take for your project to be completed. Again, you don’t necessarily have to scurry to respond to every call and email immediately. Just be prompt and courteous.

Choose an app developer that you understand and who understands you.

The better quality your communication, the better quality your finished application will be.

Overall Capability

Depending on your application project, it may be difficult to accurately evaluate a developer until after they’ve already done some work for you.

You might ask to see other projects they’ve worked on, and in some cases, you can contact their previous clients to ask about their experience and satisfaction level.

If you’re able to talk to their previous clients, ask them whether or not their projects came in over or under the final budget, and whether the project was finished on time or if it took longer than expected.

A project or two that took extra time and money isn’t necessarily a bad sign, but a history of problems with budget and delivery might indicate that the developer is disorganized or not very good at communicating expectations.

Some developers won’t refer you to their past clients due to privacy concerns, and that’s okay.

Even if you’re not the least bit tech savvy, ask about the development process.

Be sure that your developer describes their initial setup and the framework they use, the basics of their feature rollout, and what to expect during launch.

There are lots of ways that developers might accomplish the feature rollout portion. Some work in phases, while others build feature by feature. No matter how they work, though, you should have access to a staging version of your application so that you can see the progress at certain points.

Ask about their testing procedures, too, and it’s smart to determine whether or not they’ll be backing up your app.

If it’s not clear from their explanation, ask your developer how they ensure that they deliver on time. There should be something built into their process that helps them stay on track.

[tweet_box design=”default” float=”none”]Even if you’re not the least bit tech savvy, ask about the app development process.[/tweet_box]

Developers will sometimes build applications using frameworks and tools that they’ve made themselves.

In general, we recommend that you opt for developers that build with current and widely used tools and frameworks, because should you ever need to work with a different developer for any reason, it’s far easier to switch and continue improving your app.

A developer trying to build on someone else’s unique framework has to do a lot of preliminary work to reverse-engineer the system, and sometimes, they’ll advise that you completely start over in order to make a change, because rebuilding from scratch is faster and more reliable than trying to add onto someone else’s code.

Looking into past projects can give you an idea of a developer’s experience level and overall capability.

It can also give you some hints about their style and preferences, so if you like the apps a developer has built in the past, you’ll probably like the one he or she builds for you.

While looking at past projects, pay attention to how user-friendly and functional it is.

Can you navigate through the app intuitively, or does it take a lot of instruction and time to figure it out? Remember this:

Usability is always a priority.

If you ever have to choose between an app that’s easy for an average user to navigate but a little clunky for the administrator to work with, or an app that’s easy for the business that owns it and frustrating for their customers, always think of the user first.

Ideally, though, you’ll be able to get the best of both worlds by choosing a good developer.

Finally, it’s okay to ask your developer about their current workload and whether or not they’ll be able to devote enough time and attention to your project.

Both freelancers and agencies get backlogged with projects at times. Even if they’re juggling multiple projects, you should choose a developer who has a manageable schedule and is committed to delivering your app on schedule.

[tweet_box design=”default” float=”none”]UI is like a joke – if you have to explain it, it’s not that good.[/tweet_box]

The Developer Pre-nup

For the purposes of your app development project, you’re sort of married to your developer for the duration.

Just like a marriage, you’re expecting everything to go smoothly. Also just like a marriage, that’s not always the case.

It’s very important to determine what happens between you if you decide to cut ties before the finished app is delivered to you. You also want to know what happens if you want or need to take your completed app to a different developer for additional work later.

Any circumstance that locks you in with a single developer is risky. Try to avoid any situations in which an angry developer can hold your app hostage.

Aside from hostage situations, though, it’s still wise to leave yourself some flexibility.

Even if you absolutely love working with a specific dev, what happens if they decide to stop developing? What if you want to add features that are outside of their special area of expertise? There are lots of reasons why you might want or need to work with a new developer, and if you’re trapped, it’s usually an expensive and time consuming mistake.

[tweet_box design=”default” float=”none”]Just like marriage, you expect app development to go smoothly. Just like marriage, sometimes it doesn’t.[/tweet_box]

Here’s what you need to work out as part of your developer prenup:

Who owns the code?

When you pay to have an app developed, you should own the code that built it.

In most cases, the only reason your developer would own the code is because you haven’t paid them in full, or because you’ve entered into something like a lease agreement where they own and manage the app on your behalf in exchange for installment payments.

While you’re usually assumed to be the owner of the code your developer builds for you, it’s smart to ask before work starts.

Figure out where you stand now so you don’t end up fighting over ownership later.

Do you have admin access?

Even if you’re paying the developer to maintain, host, or manage your completed app, you should have admin access.

Maybe you’re completely tech illiterate right now, and that’s okay. Learning a little bit about the technology you’re going to own is a very good idea, but even if you don’t have the time or the mental capacity to learn some basic tech skills, you should still have administrator login credentials for your app.

You don’t have to actually log in, and you don’t have to know what you’re looking at if you do log in. Just be sure that you have access, because it’s your app.

There are developers that don’t want to give you admin access to your own application, because if you don’t know what you’re doing, you can make mistakes and cause problems.

It’s understandable – they don’t want to waste time fixing all the things a client breaks when they’re fiddling around in unfamiliar territory.

Here’s the thing, though:

It’s your app, so if you want to log in and mess things up, you have a right to do that.

If you break something in the back end of your app and you want the developer to fix it, you’ll pay them a fair rate for the time they spend correcting your errors. Obviously, it’s in your best interest to avoid those expensive mistakes, and it’s in your developer’s best interest to charge you a premium rate to discourage you from logging in and messing things up.

Still, it’s your right to do things wrong, and it’s your developer’s right to charge you to fix them or decline to provide further service. On top of that, if you ask a developer to spend time and effort teaching you how to use the back end of your app, they can, should, and probably will charge you for that, too.

[tweet_box design=”default” float=”none”]It’s your app. If you want to mess things up, you have a right to – & a right to pay for the fix.[/tweet_box]

If you don’t have admin access for yourself, you’re giving someone else a way to hold your app hostage, and that’s not a good idea.

Even if you pay a developer for ongoing management and maintenance, get them to create you a login, just in case. A flat refusal to give you access to your own application is a bad sign.

How is my app going to be maintained?

In a perfect world, you’d be able to build a program, website, or application once, and it would stay relevant and function perfectly forever.

But we live in the real world.

Every day, operating systems update, hackers find new ways around security protocols, users learn to expect better features, and cool apps become irrelevant as the tech world charges forward.

Put plainly, if your app is going to remain functional and practical, you’re going to need a certain amount of ongoing maintenance. So, who’s going to keep up with it?

[tweet_box design=”default” float=”none”]In a perfect world, you’d build an app & it would be perfect forever…but we live in the real world.[/tweet_box]

When a developer takes on your project, they aren’t necessarily making the longer commitment to keep your app running smoothly and securely in the future.

There’s also a strong likelihood that you’ll want to initiate more development projects in the near future, including both feature development for your existing applications and new ideas that come up as you watch users interact with your system.

For regular maintenance and possible future projects, you might consider keeping your favorite developer on hand by paying a small retainer fee. This gives you priority access whenever you have questions or ideas to discuss, and should you need security updates or other work completed, you’re already at the front of the line.

You might not need enough ongoing support to justify a retainer, though.

Ask your developer what sort of maintenance they perform, if any, and ask for their recommendations for regular maintenance checks. Each project is a little different, so general advice will never be as good as specific suggestions from your developer.

[tweet_box design=”default” float=”none”]When a developer takes on your project, they aren’t necessarily making a long-term commitment.[/tweet_box]

What happens if you want to stop work early and use a different developer?

You’ve put a lot of effort into choosing the right app developer for the right price, so you’re probably going to have a great experience.

Life happens, though. You might want to change developers for a lot of reasons, most of which are unforeseeable. It’s in everybody’s best interest to determine ahead of time what happens if one or both parties decide not to continue the project.

Though it’s not necessarily common, you may run into a disagreement during which emotions run high and a reasonable agreement can’t be reached in the heat of the moment.

By agreeing on a fair set of guidelines ahead of time, you and your app developer are prepared in case the worst happens, and you begin working together with a little more trust and understanding.

Should work stop early, the most fair and logical conclusion is usually for you to pay for whatever work has already been completed, and the developer gives you everything they’ve done to date so that you can take it to someone else.

Keep in mind that a new developer might not be able to pick up exactly where your previous dev left off.

The amount to be paid for the work completed might require some negotiation depending on how your developer bills their work, so talk about that up front, too.

If he or she bills by the hour, you’re probably going to be asked to pay for the amount of time spent on the project so far, regardless of deliverable content that’s ready at the moment.

For projects that are billed a flat fee, things can get a bit more complex. Decide how these situations will be handled before they come up, and hopefully it won’t come up at all.

[tweet_box design=”default” float=”none”]It’s in everybody’s best interest to determine what happens if you stop development.[/tweet_box]

What happens if you want to change hosts?

After development is finished, your app still has to be hosted somewhere in order for it to run.

What this means is that in order for your app to work, the code has to be physically stored somewhere. If you want to change hosting, you need a way to access and retrieve that code.

Unless there’s a compelling reason to make a different ownership arrangement, a reputable developer will give you some way to access your app if you want to change hosting accounts. It might take a short time for them to retrieve it and send it to you, but you’ll be able to get to it somehow.

Think of it this way:

Imagine you had a custom car built, and your mechanic keeps the car in his garage. If that mechanic was only willing to let you access your car on his terms, would you find that mechanic trustworthy? At the same time, you might not expect that he’s going to give you a key and unfettered access to his garage, although that’s technically an option. At the very least, you should be able to get to your car when it’s fair to both you as the car owner and him as the garage owner.

For your app hosting, you should ask where your developer hosts your app, and how you can access it should you want to change hosts.

The developer might give you login credentials – the equivalent of keys to the garage – or they might have a procedure where you request your files and database (the important pieces of your app’s code) and they deliver it to you in a reasonable amount of time.

As part of your developer prenup, the actual procedure for changing hosts is less important than the fact that you have a reasonable way to do it.

[tweet_box design=”default” float=”none”]A reputable app developer will give you some way to access your hosting.[/tweet_box]

Red Flags

If at any point in the proposal or prenup process, a developer tries to avoid giving you access to and full ownership of your application, proceed carefully. They might simply be trying to prevent mistakes on your part, especially if they’re going to continue managing your app, but they might also be holding on in an attempt to keep their leverage over you should things go badly.

Watch out for developers that frequently complain about previous clients, too. That could signify that they create problems and blame the trouble on “stupid” clients, or it might just be an overall condescending attitude. Either way, it’s not something you want to deal with.

Bravado is often a bad sign, too. Good developers never have to make clients feel stupid to prove their expertise. If a dev talks down to you, it’s usually because he or she is trying to cover their own gaps in knowledge and experience.

The same is true when it comes to bragging about “proprietary technologies” and custom built frameworks which only that developer knows how to use.

You don’t actually want to use technologies that only one developer knows how to use – we talked about that earlier in this post.

Also, some developers who don’t know how to code and build properly on the more widely adopted frameworks will create their own code using workarounds – in other words, they cut corners and call it proprietary. Using the most widely used open frameworks and technologies is almost always the best idea.

Another major red flag is poor communication. You should be able to talk to your developer when you need to, and they should be fairly open about their billing processes, the way they work, and the tools they use.

Be wary, too, of developers who won’t give you references. A lack of references or an unwillingness to show you previous projects might indicate that the developer is inexperienced – which isn’t the worst problem in the world – or it might be a sign that their relationships with previous clients is no longer amicable.

Of course, go with your gut.

If you feel that someone isn’t being honest, or you just don’t get along with them, don’t work with them.

There are a lot of developers out there, and unless you’re a difficult person, you’ll probably find someone you can work with at the price you want to pay.

[tweet_box design=”default” float=”none”]Bravado is a bad sign. Good developers never have to make clients feel stupid to prove their expertise.[/tweet_box]