🚀 How to build & launch an app in 30 days

Published a year ago

notJust.dev Newsletter 🚀

Stay up-to-date with the latest technologies and become a better developer

Hey {{ subscriber.first_name }}👋

During August, I started a community challenge - Summer Startup. The goal is to build and launch a mobile app in 30 days. Building an app in 30 days might sound impossible, but if you take the right approach, it’s something that can be accomplished by anyone.

In this issue, I will cover the strategy I use to speed up the development process and iterate faster on the product.

How NOT to build an app

The old way of building software meant spending a tremendous amount of time and effort on crafting a business plan, an in-depth strategy, and numerous market research before writing a single line of code. Then followed a period of development. Feature after feature. Without any user feedback. With the goal of having a BIG Launch. After 1-2 years, the project is ready to get to market, only to be met with 🦗cricket noises🦗. Way too often, the market demand does not correspond with the assumptions that the whole project was based on.

We can’t afford to work on a project for years only to find out that what we build is not that useful. Elon Musk has a great quote, “the biggest mistake engineers make is solving problems that don’t exist.”

Is there a better way?

The Lean Startup methodology

Lean startup is a methodology for developing businesses and products that aims to shorten product development cycles and rapidly discover if a proposed business model is viable. At the core of Lean Startups are:

Hypothesis and Validated Learning
Minimum viable product
Customer feedback over intuition
Iterative product releases
Flexibility over planning

Hypothesis and Validated Learning

First of all, we should not treat our ideas and opinions as hard truths, but only as Hypotheses.

Based on the dictionary, a hypothesis is “a proposed explanation made on the basis of limited evidence as a starting point for further investigation.”

The purpose of a Hypothesis is to be validated or invalidated. This leads to learning.

When the hypothesis is validated based on data and feedback from real customers, that’s validated learning.

Our initial goal in building a startup is to gather as much validated learnings as possible. This involves a lot of experimentation.

The MVP (Minimum viable product)

At the core of the Lean Methodology is the Minimum viable product. This is a version of your app that allows you to collect the maximum amount of validated learning about the customers with the Least Effort.

The goal of the MVP is to test the most risky business assumptions and validate that there is a need for your solution.

Build something small, focused on THE CORE feature, and get it in the hands of users as soon as possible. The MVP does not have to have the same shape or form as you envision it, but it should solve the same problem (or a subset of the bigger problem) that customers face.

If your goal is to help people move from point A to point B, and your vision of solving the problem is building a car, it’s better to start with a bike. It will solve the same need of moving from point A to point B but will take you way less time to build it.

At this stage, it’s ok if not everything is polished. It’s ok if important features are missing. It’s also acceptable if the app might crash from time to time.

We will have time to fix all the issues and add all the features, but remember: our first priority is to gather validated learning. To understand better our customer’s needs and their behavior. To listen to their feedback and prioritize product development based on what the market needs - not based on what you think it needs.

Customer feedback over intuition

Having an MVP launched, you can start to base your decisions on customer feedback over your intuition.

Even better, is to base your decisions on customers’ actions and inactions. Most of the time, customers don’t know what they want. Henry Ford famously said, “If I had asked people what they wanted, they would have said faster horses.”

Iterative product releases

Once the MVP is launched, you continue iterating on it, but this time you are not led by intuition but by customer feedback.

You fix the major bugs that affect most of the users, you work on most requested features, and you release them as soon as they are ready.

With new iterations, you should also keep a lean approach, and take the MVP concept even when building new features in the app. Don’t jump head-first into development. Implement the smallest version of that feature, and then run some experiments. Check how people are using it, and if it is something that they need. With more validated learning, you can continue improving it over time.

The Lean Startup in Practice

During the Summer Startup Challenge, my goal is to build and launch an app that will help couples and young families manage their finances. There are a lot of features that I can’t wait to jump into developing like Shared Budgets, Expense Tracking, Savings Goals, Bill Reminders, Financial Overview, Stock tracking, and Debt Management, etc., etc., etc. I can go on and on listing features that might or might not be useful for my customers. Instead of starting working on them, I want to gather some validated learnings first about how couples and families are managing their financials together.

For that reason, I will focus on getting the app into the hands of users as fast as possible. I will focus on only 1 single feature. The financial goals. In fact, I already finished the MVP version of this feature in just 3 livestreams on youtube. That took me around 10 hours of development.

By the end of the week, I will have the MVP ready to be launched, and I will start gathering feedback from real customers.

This will help me validate some of the assumptions I have and also will help steer the product development in the direction that will benefit the customers.

If you want to follow my journey, I am documenting the whole journey of building this app Live on youtube, every Tuesday and Friday.

Common pitfalls

Working with a lot of developers I saw some common pitfalls that prevent them from launching their apps.

Too much focus on the tech side

Users don’t care if you use React Native, Flutter, Swift, or any “insert a hot framework”. They want their problems solved, a happier life, and a Margarita 🍹

Premature optimization

“bUt Is iT ScaLaBLe?”

Don’t waste your time optimizing something that shouldn’t exist.

Having scalability issues is an excellent problem to have, but first, you should get there.

Prioritization

Thinking that every feature is a MUST before launching is one of the most common pitfalls that stop so many apps from seeing the daylight.

Focus on what’s important. Be scrappy and less perfectionist in the beginning. If the app can still function without a particular feature, then it shouldn’t be in the MVP.

Here are some of the most common features that trick you into thinking you can’t launch without them:

Onboarding screens
Notifications
Chat (unless you are building a chat app)
Deleting and updating non-critical data
Animations
Real-time features

Yes, some of them are important, but the app will still function without them. With fast iterations, you can always work on them after releasing your app.

Conclusion

With the right mindset and approach, building an app in 30 days sounds more realistic.

Start with an MVP and a single CORE feature
Be ruthless when prioritizing what you work on. Ask yourself if the app is still usable without that feature.
Get your app in the hands of real users as soon as possible
Gather Validated Learning through customer feedback, data, and experiments
Iterate fast and improve the app based on the learnings