Disclaimer: this is intended for those who are newer to building a tech product (0therwise you wouldn’t read an article called How to Build an App, right?). If you’re looking for an article about how you can build your very own Flappy Birdand make millions, this one isn’t it. This article is about the realities of how hard it is to build a successful app and why — odds are — you’re not going to want to do it.
App building is the Powerball lottery of the 21st century: everyone thinks they’re going to get filthy rich doing it. The difference is, building an app costs more than just $2. That’s not to say it’s not a rewarding experience for someone teaching themselves how to code, but if you don’t know what Stack Overflow is, and you’re looking to turn a profit, you may want to think again.
Building a successful app is hard, whether it is for web or mobile (likely both). It’s like building a house; it requires multiple fields of expertise, significant investments of time and money, and near-endless rounds of testing, revising, and updating. What’s more, it’s like building a house in the middle of the forest, and hoping the city will clear a road to the house and hook up the utilities all on their own — i.e., even once you’ve built the app, no one knows about it, and without visibility and traction all of your work is wasted.
But if you’re serious about building your own app, and you plan on doing it regardless of these warnings, I may have some experiential advice you’ll find useful.
It’s Expensive
If you are paying for help, it’ll likely be a minimum of around $10,000-$20,000 to build. More expensive apps may cost over $100k just to release the initial version. That’s a non-trivial amount of capital to invest in a project that might not turn a profit, and it’s not even worst-case-scenario. Kevin Rose, a serial tech entrepreneur, is currently building a new app and posting the costs online that you can use as a point of reference.
It Takes a lot of Experience
You could be likely looking at four to five different disciplines: iOS development, Android development, backend server development, front-end web development and UX design. It only gets bigger from there. Odds are, you don’t have a high-level proficiency in all of those fields. Neither do any of us; there’s a reason we specialize in one, then come together to form a complete team.
Most People Fail
Not every app makes it to market. Honestly, from what I’ve seen, a lot are abandoned mid-project due to expense and budgeting concerns, development complications, customer validation, and so forth. It’s not uncommon for management to scrap a project that that wasn’t fully fleshed out to begin with.
Even for the ones that make it to the App Store, recouping initial costs is really hard. It’s often talked about how hard it is to build the app, but comparatively, I think that’s the easy part. The hard part is getting people to actually use it. Pick a category in the App store — any category — and scroll down all the way. The bottom of the list is a boneyard littered with the bodies of unused apps, many of which cost as much as $100k to make.
Like a major movie that bombs, it’s a lot of resources to spend for it all to go unseen.
“Alright, So What Do You Suggest?”
Do your best to learn everything you can about app development. Learn about languages required to build it, learn about interaction design, and learn about marketing a product like the one you want to build. There is no easy way to do this, or we would all be rich. Ideally, you could learn enough to build a lot of the app yourself, and then hire out a really good agency (they are not all created equal) to build the parts you are incapable of. Contracting the work can actually save you money, as they already have the training, practice, and you do not have to keep them long term.
Step 1: Learn Code
Here’s the first pill to swallow: you can’t be the head of a tech company without knowing tech. If you try to build a tech product without understanding it, you’ll probably fail. If you’re serious about building an app, you need at least a basic understanding of programming, and that comes with learning a programming language.
What language is best to start with is debatable, and depends on how much you intend to use it/what you plan on using it for. If you plan on coding the app yourself, you should be aware that most Android programming is done in Java (and more recently Kotlin), and iOS is done in Swift. The goal, though, is to learn a language. Understanding code will help you know what the technology is capable of, and better lead the developers you will work with.
Another important detail affected by your coding knowledge (or lack of) is the hiring process. It’s very difficult to hire a team (whether in house or an agency) if you don’t know enough about coding to evaluate their ability.
So, bottom line, you need to know code. To be more technical: IF you know a programming language THEN proceed with building an app; ELSE learn to code, then ask again. OR, at the very least, bring on a founding partner who knows it well. 😉
Step 2: Learn Product Design
You’re also going to need an understanding of how to create a UI that is intuitive to use. This is often much more difficult than you would assume. What may seem like a good design will shockingly be hard to figure out by real users. Look for online courses in product design (these are a few quality ones). By the time you begin building your app, you’ll be grateful for an understanding of how product designers take a concept from idea to execution.
Some Food for Thought: Business or Consumer?
The consumer/business divide with regard to apps is pretty wide. Sure, a consumer app might go viral and become the next Tinder, but like our lottery example, odds are you’re not going to hit the jackpot. The market is big; there are a lot of apps out there, and it’s difficult to get traction. You might be better off designing a B2B app; one that serves a commercial purpose, and that a company is likely to adopt as part of an upgraded business practice.
Business apps can often be easier because they’re essentially an exchange of services: you’re telling the company you can fix a problem they have, and then you’re asking them how much they’d be willing to pay to make their lives easier. When an app fills a need, and that need saves a company time or money, it is easy for a business to justify the cost, which means they will continue paying you for the service, and they will tell their friends. The odds of you succeeding are typically better.
Step 3: Create a Wireframe
Next is creating a wireframe. A founder can/should complete this step before ever using their own money. A wireframe is your blueprint, your “storyboard” for the project. It’s when you put your digital intentions down on paper, illustrating the priorities and purposes of the project. Without a well thought-out and well-documented plan, your creative solution is never going to materialize properly.
There are some design tools you can use at this stage. InVision is a great tool for creating functional mockups that your test users can play around with. It will give you a product that will allow you to get great feedback.
The importance of using this test phase cannot be overstated. If something doesn’t work or is undesirable to your users at this stage, it will still be relatively easy to fix in your design phase. Changing something once you have it all coded will be much more expensive.
It is easier to get feedback from a test audience, which is a must. Really, this feedback will be crucial, so show it to as many people as possible, and get as much data as you can. The responses you get will likely be formative in the design phase.
Keep in mind, however, that you’ll need to read between the lines. There are three categories that I like to tell our clients to organize their feedback into:
- “Must Haves”
- “Should Haves”
- “Nice to Haves”
Your “Must Haves” will be mission-critical, your MVP i.e. the app will not serve its intended purpose without it. These constitute the foundation of what you’re trying to achieve. “Should Haves” are features that are very valuable, but not strictly required. They will be non-loadbearing yet central features.
“Nice to Haves” is the open-ended category for the endless list of features your potential users will insist the app has to have to be valuable. Often, these requests will be of little use, as the addition of the feature will merely bloat or complicate the app.
Once you’ve collected your feedback, you’re ready to start putting something together.
Side Note: NDAs
I’ve noticed a lot of people who have startup ideas are sometimes a little paranoid. Requiring things like Non-Disclosure Agreements are evidence of that fear that someone will steal your miraculous idea if they overhear it. Let me tell you right now that it’s not nearly as common as you think.
Here’s what it boils down to: those who would steal the idea don’t have the resources to put it together, and those who have the means to make it work usually have their own ideas (which are probably better than yours). So don’t be so anxious; you should be showing your idea to as many people as possible to better vet it out, your idea will still be there tomorrow. Besides, there’s likely already an app that does something similar to what you’re doing anyway. You will succeed because of your ability to execute, not because of your brilliant idea.
Step 4: Potentially Hire a Team
At this point, you should have already thought through the entire application and validated it with real customers. Assuming you’ve learned a bit about the actual technology, and you’ve realized you can’t do the whole thing yourself (but ideally you can build at least part of it), you’re ready to hire a team. Hiring an agency can save you time, money, and headaches. You won’t need to keep them on payroll if the money doesn’t come in immediately either.
Hire someone who knows what they are doing. Then, once they start, double-check to be sure they know what they are doing. If they are taking inordinate amounts of time completing work, their code is overly sloppy, or you otherwise see a problem that falls outside an acceptable margin for error, be sure to fix the problem quickly— it’s much easier to clean the code up early on than it will be when you have three months of work behind you. And if you wait too long, even a talented programmer may not be able to untangle the spaghetti they may have created.
Step 5: Design the Interface
This is where you need to the app to look great. Working with an experienced UX designer during this phase will be extremely valuable to both your users and the developers. Every piece of the app should be completely designed out: each screen, each button, transitions, and all the user flows. The developers should be able to take the design assets and code them up without having to create any designs themselves. Trust us, you don’t want developers designing an app unless you want it to look like Windows 95.
Step 6: Start Coding
Now it’s time to start the job you set out to do. Does it matter if you start on the front-end or back-end first? Sometimes yes, sometimes no. The key is to get your design as perfect as possible before you start coding, as that will frame the rest of the work. So hire a designer, and design it backwards and forwards. Then start coding.
Step 6a: Front-End
The front-end refers to the code that will interface with the phone or tablet’s actual architecture. That means coding in Objective-C/Swift (iOS) or Java/Kotlin (Android), as we mentioned before. Using native code will result in a smoother operation for the device, but it means you’ll have to do a lot of your work twice to build for each platform- iOS or Android.
You can also build your frontend using a hybrid web technology like with React Native or Ionic, which will allow you to release simultaneously to both iOS and Android. Most often, we don’t like doing it that way, but depending on your use case, you may find the cost is worth the gain.
If you do decide to use a native platform, start with iOS first, and here’s why. iPhone users download more apps than Android users, and they’re more likely to pay for those apps. Android users, on the whole, aren’t willing to pay for their apps, so you’re less likely to earn your sunk costs back, especially with a consumer-facing app. This will also allow you to work out some of the roadblocks on one platform first.
Step 6b: Backend
Regardless of what route you take with front-end development (or even if you decide to code both front and back simultaneously), you’re going to want to make sure the backend is architected well. Most apps today don’t just use the code from the device; they need an internet connection to function, which means they communicate with a server. The most common modern technologies seem to be Ruby, Python, or Node.js (we use Node.js for around 80–90% of our use cases). There’s plenty of other options though.
This is also the stage where you will be building a database for storing data, if you need it. Sometimes this can be the most difficult part of the process, so don’t be surprised if it takes a little longer than anticipated.
Once you’ve got the front-end and backend developed, the app should ready to start putting things together.
Step 6c: Connect the Dots → Bytes
Connecting the front and backend should create a functional product. Once the app is running, though, get more feedback. As we said above, programming is an iterative process, so if it feels a bit recursive as you update and patch, update and patch, don’t be alarmed. As Di Vinci once said, “[Code] is never finished, only abandoned”; so don’t abandon your app until you’re ready to bury it.
Step 7: MVP
MVP stands for Minimum Viable Product, the barest of bones you can put together and still have a viable product for your target customer. This is your prototype, and you want to get it out of the gate and into the hands of users as soon as you can, to start collecting more feedback.
Your MVP is not going to be perfect; it’s going to have issues and bugs. Remember, apps — like all programs — are designed to be built in iterations, not all at once. Your goal here is not to finish the app, it’s to build that prototype that proves your idea works and allows testers to actually use it.
To Reiterate…
Here’s a recap what I’ve discussed so far, just to be sure you have the main takeaways. First and foremost, our suggestion is you probably shouldn’t waste your money doing it. Most fail miserably. However, that failure can be good experience regardless. So if you do plan on building an app, here are the steps:
- Learn to code; you’ll understand what actually needs to be built
- Learn product design
- Create a wireframe you can show to developers and potential customers
- Hire a contract team to supplement the skills you lack
- Thoroughly design the UX
- Build out both the front-end and back-end of the app
- Get as much feedback as possible with your MVP. Put your app in front of customers, iterate, and make changes based on results.
Hopefully we’ve at least given you some useful advice that you might not find anywhere else. I don’t want you to waste a ton of money on us or anyone if you’re set up to fail. If you follow these steps, you’ll much more likely succeed. If you’d like more information, or have more questions to ask us, feel free to get in touch.