An introduction to building successful applications

Over the past years the application developers at VIKTOR have built many apps for many different industries. We have learned a lot from that and now want to share our experiences with you! We believe these insights are valuable to you, whether you are developing these tools, an end-user, project or program manager, domain expert, or simply anyone else in the process of creating awesome software tools. Would you like to read our complete guide to building successful applications? Download it here.

Developing software in 6 steps

When you develop a successful software tool yourself, there are six steps that you need to follow. These are: Define, design, develop, test, deploy and get feedback. Here, we will explain each step in short, and most importantly, elaborate on how you should work through the process of building awesome tools that other people will want to use as well.

First, the steps:

1. Define: Set the goals and priorities: What should the application do?
2. Design: Define in detail the features needed to achieve the goals
3. Develop: Write the code required for each feature
4. Test: Check the code required for each feature
5. Deploy: Make the application available to the end-users as part of business
6. Learn: Understand if the application helps the end-users and think of improvements

Do not follow a linear process

In this world, we build many things following a linear and stepwise process. This means you first define the end goal and then follow the steps that are required to get there. For example, think of a building. First, you decide what you are going to build. Then you lay the foundations, start adding the levels, place the roof, and continue until you have finished the construction. So, what we believe is that if we have a good plan, we just need to follow it to get a good result. But is this also true when building an application?

The risks of the waterfall method

In the software world, we call this linear process ‘the Waterfall Model’. Most people agree that this method does not work so well for building apps due to two reasons:

• Because most end-users (read: clients) don’t know the exact requirements for the application beforehand. Only after they see the software in action can they tell what is good and what is still missing or needs to be improved.
• Because it is hard for a developer to predict all difficulties that are going to occur during the development process and if the features that they invented really solve the problem of the client.

That is why we don’t believe you can make a master plan beforehand, simply follow those steps, and then end up with a successful application. It is a considerable risk; you invest all your time and energy and then have a ‘grand inauguration’ which could become either a great success or the biggest fiasco.

Be Agile

Instead of a linear method, a more versatile and explorative approach has proven to yield the best results. This one is called the Agile method. Its core principle is to collaborate with the client as much as possible and iterate a lot during the development process. This doesn’t mean we are saying that you should not have a clear goal in mind. In fact, you really should. It is just that the exact way your software will end up looking and working is something that should develop over time and in collaboration with the end-user. It cannot be defined at the beginning.

Run sprints, not a marathon

Instead of planning all details and building the app in one sit, the Agile method proposes dividing the project into a series of short sprints. After each sprint, you will deliver the most basic app that fulfils the requirements (the minimum viable product), even if it is not fully functional, so that end-users can test it and provide feedback. With that feedback in mind, you and the client agree on the priorities and requirements for the next sprints. In that way, you will always work on what provides value for the client and end with a much better product than when you would have built everything in one shot.

How long does a sprint last?

Each sprint usually lasts for about two weeks, followed by one week of client testing and feedback. We do not recommend taking longer than this if you are programming full-time. It is sometimes best to take baby steps in the beginning with new clients or on new projects and ask for feedback even during a sprint to ensure mutual understanding.

Why a user-centric approach works

Approaching software development in this way ensures that you end up with a better end-product. You also put in less effort since you lower the risk of investing a lot of time in something that clients don’t like. Even more important, including end-users into the development process results in tools that people will want to use eventually.

Our experience is that social factors are at least as important as technical functionalities. For example, end-users and especially domain experts can be very critical about the plans. In the beginning, negative thoughts may arise, like ‘This is too complex, it is impossible to automate!’, ‘I have been doing it this way for 10 years, why should I change the process?’ or ‘Will this tool make me lose my job?’.

However, things change once the first versions of the application appear and people can actually see that their feedback is being taken seriously. The synergy between developers, domain experts, and end-users grows, and the people who once were the most critic end-users will become the biggest ambassadors, promoting the application you have built together.

“We see our customers as invited guests to a party, and we are the hosts. It’s our job every day to make every important aspect of the customer experience a little better.” - Jeff Bezos

Building successful applications in practice (short)

In this section, we will give you a brief overview of the process and explain each step in short. In the next chapters we will explain the different steps in more detail and give you handy tips. Building successful applications always start with a big dream: What do you want to achieve ultimately? Next, you can begin designing the workflow required to get there, all of it. This is too much to start; that is why select a small portion of the workflow to start creating an app. After you have defined all the details, you can start designing and creating the application, not in one shot but in several short sprints. After each sprint, you will get end-user feedback (clients) and define the following steps to get closer to your big dream.

Dream big

Everything starts by defining a Big Hairy Audacious Goal (BHAG). Dare to dream, everything is possible. This BHAG will guide the development process. Don’t think about all the features yet. Rather think about what you want to achieve; for example, ‘I want to automate a tunnel’s design fully’.

Map out your process

To improve your process, you need to understand it thoroughly first. Map out your process and involve everyone you need to be able to understand all the details. Create a workflow diagram and see how the process can be improved to get closer to your BHAG. Organise a brainstorm, think about your ideal process and the benefit of the changes you want to make. Don’t overthink possible technical challenges yet.

Start small

Select a small portion of the workflow diagram and start with that. Which portion this will be depends on two things: Maximum impact and feasibility. In other words, where can you make a significant improvement with little effort? That is always a good starting point.

Make a plan

This is where you start using the Agile method. Formulate short term objectives in the form of user stories and write them down. For this you can use a product backlog. User stories are statements written from the end-user’s perspective. The idea here is to define what the user wants to achieve. Not how they want to achieve it. That part you can leave to the developers

First sprint, feedback, repeat

For your first development sprint, you should create the simplest app that fulfils the requirements: A minimum viable product. Let the end-user interact with the product and ask them for feedback. Store this feedback on a feedback board and decide the goal for the next sprint(s) together with the end-users. Repeat this until you reach your BHAG.

The full process of building successful applications

Want to learn more about how you can create successful applications yourself? Over the past years, the app developers at VIKTOR have build numerous of apps. They've compiled all of their knowledge into this guide to provide you with tools, methods, and tips for building your own application that you can start using right now!