Even if you’ve got the best app idea in the world, you believe in it 100%, and you’re willing to do whatever it takes to make it work, not knowing where to start could be the simple reason you fail.

Because I’m in the app development business, people often approach me to talk about their app idea. The ideas are all pretty different, but everyone asks me the same thing: What should my next steps be?

Define

In order to turn your idea into a tangible product, you’ve got to understand its every detail.

For example, let’s say you want to create a ride-sharing app. Your goal is to make travelling easier and less expensive. But is that enough information for a designer to design it? Is this enough for a developer to code it?

Of course not.

In fact, this isn’t even enough for you to fully understand your own business. There are many questions that you need to answer, like:

• How will you determine the cost of the trip?
• What’s your target market?

Perhaps you want to focus on students with long commutes home. Will there be multiple car options for passengers to choose from? Can you select the pick-up time in advance, or does the car come the moment you order?

To answer these and other questions, at CodeCarrot we complete 2 very important documents for all of our clients: a features list and an app business canvas.

The features list includes all the features of your app. Start building this list with the main features, and then include secondary features (such as login and registration feature).

In the case of a ride-sharing app, the main features could include:

1. As a driver, a user can create a trip by selecting the start and end point. They can also add information about their car (make, model, color, number of available seats).
2. The cost of each trip per passenger shall be calculated using formula: total trip distance in miles MULTIPLIED BY $2 and DIVIDED BY the number of available seats PLUS $1 transaction fee.
3. The driver revenue per completed trip shall be calculated using formula: total trip distance in miles MULTIPLIED BY $2.
4. Users can see available trips on the map that will show their starting point, or in a list format. Trips that are shown can be filtered by choosing starting point, end point, and driver rating.
5. As a passenger, a user can order a ride by selecting a trip from one of the available options

In other words, when creating a features list you need to second guess every assumption you have and be as detailed as possible. Your final features list will most likely have at least 20 feature bullet points—no matter how simple your app is. Once this is done, you’ll have a well-defined idea that you can start prototyping.

Research

But before you invest any more time, make sure your idea passes a business stress test.

To do this, we use our special App Business Canvas. It’s a slightly modified version of a well known Business Model Canvas.

“Can your app idea pass a business stress test?”

Let’s go through its main components:

• Target audience. Who are the users that will benefit from your app the most?
• Value proposition. How does your application benefit users?
• Platforms. What platforms will the app work on? Is there a web version? Customer relationships. How can users communicate with you? How do you prevent a bad review on the App Store?
• Monetization. How will your app earn money? Cost to download? Freemium? Ads?
• Key resources. What’s needed for the app to function after it’s developed? For example, does your app require at least 10 drivers in each city for it to provide ride-sharing services?
• Key activities. What’s needed for the app to function well? For example, do you check driving history? Do you ban drivers with low ratings?
• Key integrations. What third-party work will you need? Are you using maps? Accessing a database of restaurants?
• Cost structure. Who will wireframe, design, and develop your app? What would that cost?

Prepare

Now that our idea has passed our business stress test, it’s time to prepare for the execution. Generally speaking, software products can be built using one of the 2 popular methodologies: agile or waterfall.

To keep it short, waterfall approach requires that you create a product in stages. For example, first you create complete wireframes of the whole app, then you create complete design of the whole app, and only then do you go into development and fully develop the app.

Agile approach focuses on features as opposed to stages. So, first you might choose to build a trip creation feature. Then you’ll design just this section, and before anything else is designed you’ll develop this section, resulting in a fully designed and developed trip creation section.

The main advantage of the agile approach is that it allows you to pivot at any moment. If after building one feature you decide to change something about another section, you wouldn’t lose any time already spent designing it as you would with waterfall. This difference is important to know as, following our agile approach, we suggest starting with the main user stories and first working on them before building out other parts of the app.

So first you need to create a block diagram with your main user story. In our example with the ride-sharing app, it’s important that we also have 2 user types: passengers and drivers. We need to prototype both of them.

Your passenger user flow can look like the one below:

Execute

Once you have your main user flow, start wireframing it. Note that because my organization works with clients, we always do wireframing before design so we can confirm the outline of the app before moving into stylistical details.

However, if you’re a designer and you’re working on your own app, you might want to skip wireframing and design right away—you probably already have some style you like in mind.

“Your wireframes don’t need to be pretty—keep them simple.”

When wireframing, remember these simple tips:

1. Don’t use color. Color will distract you from creating the perfect flow.
2. Use real content. One of the most common problems is using a placeholder 3-word sentence that will need to be replaced with a 10-word sentence in the real design, shifting your whole screen out.
3. Avoid barriers of entry. Don’t force people to register or do anything else before their desired end goal unless it is absolutely necessary.
4. Keep it simple. Remember—wireframes don’t need to be pretty. Don’t overcomplicate things. Stick to creating a perfect flow, not a gorgeous design. That comes later.

Once your wireframes are done, it’s time to begin our test and adjust phase.

First, we want to get feedback from real people—and we can’t do that without first creating a prototype. Once the prototype is ready, go out and ask real people what they think. Start with your friends and family. Just be careful to talk to people who will give you honest feedback. Welcome negative feedback—it’ll tell you what you missed.

After the initial feedback round, go back to your wireframes and make the adjustments, then move to the design. This will start a loop that you should repeat for every section of the app: Wireframe -> prototype -> gather feedback -> adjust -> design -> prototype -> adjust.

Just do it

The best advice I ever heard came from Nike: Just do it! Stop wasting time—get out there and start working on your app.