How an app gets built — the app development process step by step

In short

  • Building an app takes four steps — meeting, design, build, and launch and care.
  • You see how the app will look and work before it is built, and we show you finished parts as we go.
  • The App Store and Google Play review mobile apps before release, and no supplier controls how long that takes.
  • You bring knowledge of your business, decisions and feedback, while we bring the design, the build and care after launch.

How an app gets built with us comes down to four steps — Meeting, Design, Build, and Launch and care. First we find out where your company loses time, then we show you how the app will look and work, we build it in parts, and after launch we keep developing it with you. At every step you know what is happening and what we need from you.

If you have never had an app built, the process can feel like a black box — you sign a contract and then hear nothing for a long time. It does not have to be that way. Below we walk through the app development process from the first meeting to release on the App Store and Google Play, what you do at each step and which mistakes are worth avoiding.

What does the app development process look like?

This table sums up the whole process. Each step is covered in more detail below.

StepWhat we doWhat you do
MeetingFind out where you lose timeExplain how things work today
DesignShow how it will look and workSay what fits and what does not
BuildBuild in parts, show finished workTry out finished parts
Launch and carePut it into operation, keep developing itReport what to improve

The steps follow one another, but they are not sealed off from each other. Because we show finished parts as we go, you can respond early, and after launch the app keeps growing.

Meeting — where your company loses time

At the first meeting we talk about your business, not about technology. We want to know where people do the same work twice, where information gets lost and what takes up most of your time. A typical example: orders arrive by e-mail and phone, someone types them into a spreadsheet and then again into the stock system.

Together we put into words what the new app should deliver — less retyping, an overview of jobs, faster replies to customers. This is often where it becomes clear whether a mobile app or a web app will help you more, or both.

What you do: explain how things work today and show us the documents you work with — an order, a delivery note, a price list or a spreadsheet. If you can, bring along the person who does that work every day.

Design — see the app before it is built

In the design we show you how the app will look and how people will work with it. You will see, for example, what a technician does when they take on a job, or where a customer finds their invoices.

The design is the cheapest place to make changes. Adding a step or moving a button in a design is easy, while in a finished app it means rework. The design also pins down the scope, and the exact price and timeline depend on scope. That is why they can only be discussed honestly once there is a design, as we explain in how much app development costs.

What you do: go through the design, show it to the colleagues who will use the app and tell us what fits and what does not. Decide what is essential at the start and what can come later.

Build — in parts, with finished work shown as we go

We do not build the app as one block that you only see at the end. We build it in parts and show you finished parts as we go. It pays to start with the part that saves your company the most.

That way you are not waiting for the finish line. You try out each finished part, and if something does not fit, it can be adjusted before further parts are built on top of it. The build also covers connections to your accounting, stock, online shop or CRM, so that nothing is retyped by hand, as well as testing on different phones and in different browsers.

What you do: try out finished parts, ideally with the people who will use them, and give us feedback. Decide on the questions that come up during the build and prepare the data to be moved over — customer lists, price lists, stock records.

Launch and care — the app at work

Launch means real people start using the app. We put a web app into operation and your staff log in through their browser. Mobile app development has one more step — publishing on the App Store and Google Play.

Getting onto the App Store and Google Play

Publishing requires a developer account on both the App Store and Google Play. If the app is to appear under your company’s name, the account should belong to your company. Verifying a company account can take a while, so it is worth setting it up early.

To publish, you need a name, an icon, a description, screenshots and a privacy policy. If the app requires a login, the reviewers also need a test account.

The App Store and Google Play then review the app. They check that it works, that it matches its description and that it follows their rules. Neither the supplier nor you controls how long the review takes, and sometimes a store asks for changes. Every later version goes through review too.

If the app is only for your employees, it does not have to be publicly searchable in the store. The App Store and Google Play both offer ways to handle this.

Care after launch

Real use shows what needs adjusting. The app also needs changes when new iPhone and Android versions arrive or when the stores change their rules. And over time you will want to add new features. That is why we keep developing the app with you after launch.

What you do: make sure your people start using it and understand why a familiar routine is changing. Collect their feedback, tell us what needs improving and decide with us on the next steps.

Common mistakes when building an app

  • Building without a design. ‘We’ll sort it out during the build’ usually ends with finished screens being redone.
  • Wanting everything in the first version. The build takes longer, costs more, and people get too much at once.
  • Designing without the people who will use the app. A technician or a warehouse worker knows best what slows them down today.
  • Having no one who makes decisions. When questions wait for answers, the work stands still.
  • Forgetting the data. Moving customers, price lists and stock records out of spreadsheets needs planning, not a last-minute rush.
  • Leaving the App Store and Google Play until the end. Company accounts, texts, screenshots and the privacy policy are best prepared during the build.
  • Testing only in the office. A technician in the basement of a residential building has a weak signal and gloves on, so test the app where it will really be used.
  • Treating launch as the finish line. Without care, the app goes out of date and people drift back to spreadsheets.

How we can help

Our app development always follows these four steps, from the first meeting to looking after the app once it is live. You can see apps we have built among our projects. If you would like to talk through what an app for your company could look like, book a meeting with us.

Tell us what app you need.

We will get back to you with a way to build it so it saves your company time.

Representative
Mgr. Matúš Jackulík, MBA

What would you like to solve?

We will only use your details to reply to you.