12 App Development Lessons That Saved Us & Clients THOUSANDS Of Dollars

Save time, cut costs, and minimize stress from the start

Every beginner in app development learns from mistakes. 

The not so smart ones (like us) require first-hand experience.

We learn not to pee on electric fences – after getting electrocuted.

Smart beginners like you learn from other peoples’ mistakes.

And so, we thought we’d share 12 app development lessons we wish we’d known six years ago, when Upstack Studio was founded.

Takeaways from our app development lessons

These app development tips will help you:

• Avoid unnecessary costs
• Avoid unnecessary conflicts
• Be efficient with your time
• Find ideas worth working on
• Suss out people that may not have your best interests at heart

Ultimately, you’ll start making decisions only after considering relevant factors.

At the same time, you’ll learn to recognize and ignore distractions disguised as relevant factors.

You’ll think like a seasoned founder.

And seasoned founders don’t go around peeing on electric fences, because they know…

There’s no replacement for qualitative user interviews

We don’t care how many AI tools promise to generate detailed user personas.

You’re not building an app for AI – you’re building for people.

It’s as irreplaceable as a mother’s love – don’t tell us you’d find an AI tool to replace that too?

You need to find real humans who fall into your target audience. 

If your app is for athletes, find athletes. 

If your app is for disabled athletes, you need to find disabled athletes. 

How many? There’s no definitive answer, but we’ve always found five to be a good number.

From these five people, you need to confirm three things:

1. they are facing the problem you’re thinking of
2. they are tech savvy and have access to necessary infrastructure
3. they’d actually pay for your solution

Number three is super important – all five people may want your solution, but none will pay for it. 

Socialists, right?

Doesn’t mean the project can’t go on, but it tells you a subscription based business model isn’t gonna work.

Knowing this from the start, you can already look to other app monetization strategies.

You’d never know without those interviews.

Next,

Always listen to users, but focus on solving problems

People don’t know what they need – or don’t need, for that matter.

It’s not an individual thing, it’s a job function.

Most guys are normal 99% of the time, then turn into a nervous wreck when asking a girl out.

Same thing with people giving user feedback.

You could take a 200-IQ Jimmy Neutron who levitates stuff via telepathy,

Now ask him for user feedback on an app and he turns into Patrick Star from Spongebob Squarepants.

So when it comes to iteration, even if 100% of your users say they want a feature, don’t roll out that feature just yet.

Actual changes must be supported by data from user journeys and app usage. 

Here’s an example:

Multiple users are asking for more space, but none are close to maxing out their storage.

The request makes zero sense, so why are all these people complaining about the same thing?

Well, maybe the UX copywriting is misleading.

Maybe a bug is showing false storage levels.

Look for weak links, and you’ll find them. 

Better to be first than best on the market

Aim to be both if possible, but we’re looking at an ‘either, or’ situation here.

If you ever have the chance to be the first to digitize a service, do it.

In a world where there’s nothing new, you’ve just created something new.

Whatever demand is there, you are the only supply.

Just make sure key features work and the UX is good enough for Grandma Josephine to find her way around, and you win her undying loyalty.

See, once people become users, treat them right and they’ll stick with you even if a slightly better competitor comes along.

The operating word: slightly. 

Users will jump ship if the new competitor is significantly better. 

If you let that happen, you honestly kind of deserve it.

Remember Yahoo?

They let themselves get completely outclassed by Google and lost most of their users.

Amazingly, there are still people who use Yahoo – a testament to the lasting power of being first.

Still, not being first, or even the first 50, shouldn’t stop you because…

There’s ALWAYS room for new competitors on the market

Imagine if the folks behind Google decided not to proceed because Yahoo existed.

And yet, we’ve heard so many founders say they got discouraged because someone had already turned their idea into an app.

Worse still, a successful app (cue shaking fists at the sky).

Now they have two options: swear vengeance or move on.

There’s actually a third option: Build it anyway.

The success of those earlier apps means your idea validation has been done for you. 

You can now build an alternative that directly addresses gaps in the original. The beauty is that any iteration or USP you implement is built off the back of a proven idea. 

Speaking of USPs, there’s one you should approach very carefully.

Remember that gimmicks never last

We love a good gimmick when used for its intended purpose: attracting attention. 

For long-term user loyalty, not so much.

It’s 2023 and right now AI is super hot – everyone’s racing to build an AI-powered app.

Every time there’s a chance for a cash grab, quality goes down the drain.

When we were first starting out, Uber and Grab had just gone big and everyone was trying to create their own version of a ride sharing or house renting app.

Eight years later, Uber and Grab are still around – but the copycats are long gone.

Same thing will happen to many of these AI apps – most will be forgotten in 12 months, and won’t even have any profit to show.

Look, you should keep up with trends and what’s marketable. 

But for staying power, you need an actual long-term solution to a problem.

Learn and apply Agile app development methodology 

Serious about app development?

Then read up on Agile methodology. 

For startups it is the way to approach product development. 

Agile deserves its own discussion, but here are some defining characteristics:

1. You work in  2 – 4 week blocks called sprints; in between you review so you have constant feedback about whether or not you’re on track
2. Short daily team meetings to highlight issues and action items for the day, and most importantly
3. At the end of every sprint, real users test new features and provide feedback.

This focus on short, cyclical steps means changes are made based on timely feedback and with the least amount of resources being wasted. 

If we hear one more veteran founder saying Waterfall again, we’ll push them off one. 

Choose no code app builders that allow code exporting

For you no code junkies, one feature that can’t be overstated is the ability to export code in an open source codebase.

When you don’t have a validated idea, it can be easy to dismiss the dangers of vendor lock in.

Then the idea gets validated, and If you want to go beyond no code, a developer will have to rebuild it from scratch.

Worse, if your app builder introduces breaking changes, you can’t take your app to an alternative host.

It’s stuck.

Imagine leaving a profitable business with the landlord because they increase the rent.

That would be insane.

Your business should be able to go with you.

So make sure your no code app builder lets you export the code.

No code developers are a great middle ground

Non tech founders go no code to avoid the high – but deserved – fees of app developers.

And so they go into no code with the idea of doing it all themselves.

Just know that there are developers specializing in using no code and low code app builders.

They’re not shady back alley developers either.

Many no code platforms have official programs where developers or experienced users can sign up as platform specific developers.

The fee will always be cheaper than a full fledged developer, and you save a ton of time not learning the system yourself.

Speaking of which,

Saving time is THE best way to save costs

This is also our way of saying go cross-platform if you can.

With one codebase, you establish a presence on two of the biggest app markets: the Google and Apple App Store.

Unless:

1. Your app needs native features, or
2. Needs to access the device’s hardware, or
3. You’re absolutely certain you only want be on one app store

It makes zero sense to choose a native codebase. 

Not much to say here. Cross platform is cheaper, faster, more versatile and lets you reach a wider audience with less effort.

If you’re the developer, outsource non-developer work

The actual app development is everything.

But running an app requires more than everything, and you’d still be surprised by how much extra work there will be.

A huge one is marketing – you’ll want a campaign to advertise your new product.

Then there’s customer support – the more popular you get, the more Grandma Josephines you need to manage.

Here’s a non-exhaustive list of job functions unrelated to development:

• project management, 
• competitor research, 
• app store optimization, and 
• analytics and tracking.

These are essential functions to give the app the most visibility and keep the project on track. 

If you’re a one man team, this is the perfect time to use AI tools to automate your scheduling, marketing, content creation, lead generation, and analytics. 

Here’s our favorite AI tool aggregator – have fun, and you’re welcome.

Stop asking developers for quotations in the first email

This one comes from the heart.

Our founder Adrian gets 10 emails a week asking how much it costs to build *insert app here*.

His reply is always the same: I’m sorry but without knowing your needs, I have no idea.

Any developer that gives a confident quotation here is guessing at best, or worse, trying to lure you in with lowball prices. 

They know it’s going to cost more; they’re hoping to hook you in and by the time you realize you’ve sunk in too much to stop.

Instead, the first email should have an app brief with details about your app. 

Also, ask the developer how their requirements gathering and product roadmapping works.

We’ve got an app brief template you can use to describe your app when you reach out to developers, and yes it’s free!

And now the last lesson – something we did implement from the start and are forever grateful for. 

For the love of God, have a product roadmap

In conventional SaaS development, a product roadmap is a document or plan that contains the high-level vision of an app and how to get there within a specific period.

It contains:

• Your goals and ultimate vision
• A list of planned features, functionalities, 
• A timeline of planned milestones and dates for delivering specific features

In a team, this document aligns the different members.

We’d argue that when you’re working alone, it can be just as easy to lose sight.

Easy to prioritize the wrong things, easy to fall behind schedule without knowing, and easy to get demotivated without frequent feedback.

The product roadmap keeps you accountable.

And it’s not set in stone. – halfway through your development, your vision might change.

The roadmap is the law: Always follow the law.

If circumstances change, don’t break the law. 

Modify the law if you must.

But always follow it. 

This is how you see a project through to the end.

Hey there stranger, thanks for reading all the way to the end. Consider joining our mailing list for a one-stop resource on how to develop an app with no experience and become a well-rounded founder. Get a nifty list of questions to ask app developers when you sign up!