From Idea to App

Creating an app is a complex process, and this blog post series will help demystify it.

There are plenty of resources online on individual topics, but very few go into practical details, explaining a project end-to-end.

We are going to build up a task list app from scratch in the upcoming posts of the series, focusing on explaining the process step-by-step from ideation, planning, design, development, and release, focusing not only on what we are doing, but why.

By the end of the series, you will have a complete understanding of how to manage a project, tackle challenges, and it will give an idea of how we work.

We will guide you through all steps in more detail in the upcoming blogs. Below is a very brief summary of what we will cover.

Key participants

• stakeholders
• users
• product managers
• designers
• project managers
• developers

The goal

At its core, the purpose of an app is to create value, but how it does it is a complex question. Without going much into business details, it must eventually generate more value than it costs, while keeping up the pace with competitors.

Ultimately, all that matters is to create the most value using the least amount of resources.

For example, perfecting a cool animation for a website takes time away from developing essential features.

It’s all about correctly distributing resources.

Discovery, user research

Everything starts with an idea, but while some ideas may seem great at the beginning, it’s up to your users to decide if it’s worthwhile.

Different stages of a product require different strategies to figure out if the users will want it.

There are techniques like market research, user testing, surveys, or MVP (minimum viable product).

Many startups have failed by blindly developing applications, perfecting them without making sure their users need them.

From idea to plan

After having an idea of what needs to be built, we must have clear objectives and answers to important questions. The product manager has to clearly define:

• The problem - why? (e.g. users find it hard to create tasks)
• The solution - what? (e.g. put a create button in the header)
• Acceptance criteria - how? (e.g. if the user presses the button, the create task screen should appear)

Design

Imagine the above as a blueprint for the designer to create sketches of the solution which then goes back to the product manager to approve. In the above example, it would be redesigning the header, designing the location, size, and appearance of the “Create task” button.

Value/effort

As mentioned before, some features don’t provide enough value to make it worth spending time on implementing them.

Let’s use a 1-5 scale for the examples below to demonstrate the value-effort ratio.

For example, implementing different themes for the user interface provides some value to users who like to customize the app’s appearance, but very few users will stop using it just because it has only one theme. On the other hand, it requires significant time investment from both design and development sides.

Value: 2/5, Effort: 4/5

Following the above example, users gave feedback that creating a task is not always straightforward. If users request a feature/fix, it immediately has great value. Implementing a “Create task” button in the header is straightforward, so this is worth implementing.

Value: 4/5, Effort: 1/5

This can sometimes be estimated at the planning or design level, but the most resource-heavy part of software projects is development. Developers give an estimate on the complexity and time required to implement a feature, and the product managers decide if it’s worth the effort.

Once the final decision has been made on whether a task will be implemented, the design is refined for production.

Project planning

A project is broken down into hierarchical parts. For example, the largest milestone is to create the MVP, which is then broken down into tasks like initializing the codebase, selecting the tech stack, creating a design library, authentication screens, etc., and then each of those is further broken down into small, manageable parts.

Larger tasks are mapped out on a timeline with estimated completion dates, while their smaller tasks are planned just a few weeks in advance, allowing for flexibility when unexpected challenges come up.

This may seem complex at first, but we will cover it in more detail.

Development

After agreeing on what needs to be done, developers begin working on implementing the requirements, following the acceptance criteria.

We’ll guide you through the development process in detail when we reach that point in the blog.

Once a developer finishes a task, the work is marked as ready for review. At this point, other developers check the work to ensure everything is correct before it gets added to the main codebase. This process helps catch any mistakes and keeps the project on track.

Testing

Testing is usually done at multiple levels, and we will go into it in more detail later. The goal of QA (quality assurance) is to make sure the development matches the acceptance criteria.

Deployment/release

Deployment is also usually done in multiple stages, and it represents a live environment, being able to test the application in the state of how the users are able to use it.

The final stage of deployment (also called release) is when the app goes live to your users.

Conclusion

While this process might seem complicated or even excessive for smaller projects, successful companies follow it for a reason. Starting off correctly may involve some initial overhead, but trying to fix things halfway through is so difficult and time-consuming that many companies remain stuck in inefficient, unstructured ways. As they grow larger, they can't afford to adapt. This creates a "snowball" effect— the more work done without structure, the harder it becomes to change, and it eventually blows up.

In this blog series, we will demonstrate how this is done in real life, so stay tuned!