Everybody wants to make the next Snapchat. The proof is in the marketplace. App development as an industry is at an all-time high. I know because I’m riding this wave to the bank. At NorthOut, I help startups design and develop apps that smoke the competition.

If you’re reading this, you’ve probably brainstormed some “brilliant” app idea that you think will make you the next Mark Zuckerberg/Travis Kalanick/Elon Musk.

I’m here to help you avoid the biggest errors that plague first time app publishers. If you’ve done your research, you’ve probably heard of most of these. If I do a good job, you’ll walk away with an idea of what to do as well as what not to do.

#6 They try to build it all

The first and most obvious mistake that arose in our discussions was the “build-it-all” theory. The build-it-all theory states: “Once an idea is born, it becomes a gravity-well for additional, tangential ideas, that take on a similar importance to the original idea.”

Basically it works like this:

"I have an awesome idea about an app that helps _________ do __________."

Then I think: "Well this idea would be better if it could also do _____________."

And: "Oh wait, if it did ___________ then we could do ______________ which would make us $______________."

....

It goes on like that for a while until you’ve got a tangle of unvalidated ideas. All of which seem important, because you haven’t tested any of them.

This is a great example of vision without data. It’s awesome to have vision. It’s awesome to be an “ideas person”. Shoot, I’m an ideas person. That’s why I can tell you, don’t try to build it all.

“Then, Justus, what should I build?”

Keep reading grasshopper. Mistake #2 will tell you.

#5 They didn't have a technical person on their side

This was my big mistake building my first app. I had this big idea for a social network would buy and sell instrumentals and lyrics and record freestyle raps and blah blah blah. It didn’t matter how good or bad the idea was, because when it came time to build it, my specifications were sloppy. I didn’t know how to work with developers. I didn’t understand their language, and I couldn’t make intelligent product decisions.

Do as I say, not as I did. Get a technical co-founder or advisor.

Nate Dionne, Founder of GamerDuel and former CTO of Barstool Sports, emphasized this point. He said, even if you don’t find a technical cofounder, “at least find a technical person to help you interview and vet development shops”.

#4 They didn't vet the partner

It’s worth noting that not vetting the partner can be huge mistake for a lot of founders. Vet your partners at every step of the way. When I joined NorthOut, I knew that Monesh (the founder) had a decade of experience working for Sapient. I’d also worked with him on projects at my last startup. He knew me from our time working together. That quality time is an irreplaceable medium for vetting a partner’s possible compatibility.

Talking with Nate made it clear this mistake is more prevalent and multi-faceted than might be obvious at first glance.

When I say “partner” I mean a technical co-founder or a development shop like NorthOut. Either way you should vet the entity.

Nate pointed out some of the technical and legal aspects:

• Be sure whatever code is produced belongs to you or your company.
• Be sure the servers belong to you or to the company.
• Be sure they use Git and GitHub for version control. The GitHub account should be in your company’s name. The online repo should be private.
• They should care about scalability. They should write clean, well-documented code. This is doubly important for agencies so that you can transition to an in-house team if the product does well.

#3 They shop on price and they bet the house

Depending on complexity. Most apps take time. As we all know, time is money.

Apps take time and money to build. There is no way around it. Software engineering is exactly that, engineering. These are intelligent people building sophisticated products. You aren’t going to get a good product for a less-than-good price.

It’s better to get a little bit done at a time, building slowly towards a reasonably useful MVP, than to quit your job and have a lump sum that doesn’t cover the cost of multiple iterations. Nothing great is built in one version.

This one is pretty simple. If you don’t have the budget, build it yourself. Or, if you don’t have a budget and it’s a brilliant idea, email me ([email protected]) and I’ll build it for equity and/or profit share..

#2 They try to move too quickly

With “agile” being all the rage these days, many non-technical app-makers mistake "hurry" for "agility". Just because you’re building something, doesn’t mean you’re Agile.

Also, Agile is a framework for smooth and flexible development. It is not a top-to-bottom product lifecycle process.

At NorthOut, our process looks something like this from a high level:

1. Ideation
2. Validation
3. Discovery
4. Design
5. Development
6. Deployment
7. Iteration

Notice steps #2-4. Many new entrepreneurs skip those. Fellow developers reading this are nodding their heads. We’ve all had a client come to us with an “idea” and nothing else.

It’s not your fault that you don’t know the whole process. Most new entrepreneurs come to product development with minimal understanding of product lifecycle.

It is your fault if you ignore expert advice and insist on “just build it”. You will spend money and end up with a product noone wants.

Graham Siegel, COO of BigWordClub echoed this point:

"The first mistake is that they actually made an app. There are things you can do to develop the idea before you actually develop it. Get a sense of demand, interest, before you go through the heartache of developing it."

The other problem that arises from a rushed production process is quality. If your developers rush, they write worse code. If your designers rush, they do less research, less analysis. Don’t rush your team. You hired them. When you rush, you don’t pick the right partners, because of a blind adherence to an urgency mindset.

#1 They set unreasonable expectations

To illustrate this mistake, I will provide some examples of reasonable and unreasonable expectations:

Reasonable Expectation About Your First Build

Your first version will be embarrassing. If you’re lucky, it will solve a single problem for a specific type of person.

Unreasonable Expectation About Your First Build

Your first version will be a beautiful, reliable, responsive homerun. It will have a rich set of features and users will gravitate to it like astral bodies falling from the heavens.

Reasonable Expectation About Beta Testing

Your friends and family might beta test the app. They’ll give you shitty advice on what direction to take the product since they probably aren’t the target market. If you’re smart, you’ve got a friend (or a few)  in the target market who’d be willing to take it for a spin.

By the way, you’re not actually in Beta yet. This is an Alpha test, because the product still sucks.

Unreasonable Expectation About Beta Testing

Not only will people line up to beta test your product, they’re going to care about it as much as you do.

Reasonable Expectation About Growth and Traction

If your shitty Alpha test goes great, you’ll have a few people who find some value in your app. After Alpha, that number improves as you work out the bugs and add some glittering new features. Maybe you’ll have a few hundred users when your beta arrives.

Unreasonable Expectation About Growth and Traction

Alpha? What’s alpha? We’re doing it live. No marketing required. We’re going to build it and they will come. They’ll find it, because the second one person hears about it, they’ll invite ten of their friends. And each of those friends will invite ten of their friends! Mwuahahahaa!

Note: You can safely ignore any expectation that ends in rapacious cackling.

Reasonable expectation: You will have to adjust your expectations.

I spoke with first-timer Craig Carpenter (CEO of RELAY) in the research for this piece. It was really enlightening to get the perspective of someone who is (SUCCESSFULLY!) building his first app.

He told me his big mistake had been around assumptions and expectations:

"I assumed that excited beta testers would set aside a lot of time to offer feedback… People get busy though and everything takes longer than you think."

Craig has done a great job bobbing and weaving to stay ahead of major issues. Now he’s got an awesome product with paying customers.

Additional wisdom for first time app makers

Here are some nuggets I got while chatting with experienced technologists and app makers:

Victor Zeng, Craig’s partner at RELAY, told me "Everybody is trying to make the app for themselves." which is a bad idea, according to him, because usually the app’s target market isn’t you.

He also scolded people for trying to go cross platform too early: "People get lazy, they try to build a Titanium app. Or build a jQuery mobile. They should go native."

Shawn Holland, an experienced mobile developer leading the team at ChefTap echoed Victor’s sentiment: "Almost always go native"

Shawn also stressed the importance of QA and user testing: "When you release an app, it's global instantly. If you have usability issues you’re gonna get flooded with support emails, it's gonna drag you down."

Craig also mentioned how important it is to abide pricing convention:

“After a great initial response to RELAY, we didn't think we needed to offer a trial at launch. We learned that even if others see the value in your product, you’re still unproven in their eyes. Give them an opportunity to try before they buy.”

Conclusion + A Bonus Mistake

A lot of this should be common sense in business by now. Work with smart people, do your homework, you get what you pay for, time is of the essence, expectations often lead to disappointment, etc.

Rather than hammer you with knowledge you’ve just read, I’ll wrap up with a less obvious mistake a lot of entrepreneurs make:

They are an asshole.

“What? But Justus, what does being an asshole have to do with making apps?”

Everything. The main reason people are assholes is because they lack empathy. Empathy is everything in business:

• Empathy makes you better at choosing a partner.
• Empathy makes you better at identifying problems in the market.
• Empathy makes you better at designing solutions to problems.
• Empathy makes you a better leader.
• Empathy makes your team work harder for you.
• Empathy makes people like you.

So, to wrap up: Have empathy and don’t be an asshole.

P.S. If you liked this post, please share :)

P.P.S. If you're looking at building an app or website, shoot me an email: [email protected]