Web and mobile apps for businesses — a guide to building them, decision by decision

This section is for people who commission an app, not those who code it: a business owner, a department head, whoever has been landed with "sorting out the system" because a process no longer fits in a spreadsheet and an inbox. We don't explain programming languages or architecture here. We explain the decisions you have to make for an app to get built, fit the budget and actually get used.

There are five of these decisions, and they come in a set order. Each one narrows the next: the scope of the first version depends on what's being built at all, the price depends on the scope, the timeline depends on the price and who does what, and the route to the user depends on everything before it. That's why this section is organised in that order, rather than by topic.

If your question is closer to "is this worth it?", "off-the-shelf or our own?" or "what kind of system for CRM, booking or stock?", start with our section on business software — that's where the business questions live. This section is about how to build.

Five decisions, in order

The map below brings the whole section together in one picture: for each decision, the question companies bring us, what that decision settles, and the article that answers it. You don't have to read everything in order — but if you're starting from scratch, this order will save you doubling back.

"We don't know whether we need an app or whether a website will do"

This is the first question, and the one most often skipped. A website describes a business and its process: who you are, what you offer, how to get in touch. An app handles that process: it takes an order, shows a job's status, records a submission, joins data from several places. If what you need can be done with a contact form and a clear description of what you offer, an app is an unnecessary cost. If customers or staff need to do something in it — log in, change something, check something, approve something — a website stops being enough.

The line isn't always obvious, because today's websites can do more than they used to, and simple apps are sometimes cheaper than they look. We explain what exactly a web application is, its main types — a customer portal, an internal panel, a sales app — and how to tell that your business already needs one, using examples of apps we've built for ourselves.

This decision settles whether you're building a system at all. It's worth making deliberately, before anyone starts pricing features.

"We have more ideas than budget"

Once it's clear that the app has to be built, a feature list appears — usually longer than the budget allows. The most common reaction is "let's start with an MVP", which in practice means the same features, done more cheaply. That road leads to a product that tests nothing.

An MVP, or minimum viable product, is something different: the smallest version that answers one business question — for example, whether customers will place orders themselves instead of phoning. The question sets the scope, not the budget, and the hardest part of the work is writing down what you're not building. We show how to cut scope with the MoSCoW method, how an MVP differs from a proof of concept and a prototype, and what to measure the result by, using the scope of our own CRM and the history of our booking module.

This decision settles the budget and timeline of the first version — and whether you'll know more once it's running than you did before.

"We got three quotes and each one is different"

Three quotes for the same app that differ by a factor of several are the norm, not the exception. The difference rarely comes from the hourly rate. It usually comes from what each contractor understood as the scope, how many hours they allowed for it, and what they built into the price — testing, design, launch, maintenance.

There's no single market figure for what it costs to build an app, because we found no published price list for building software in Poland. What there is instead is a calculation you can reconstruct yourself: where the rate comes from, how to read scope in a quote, and what an app costs after launch. We set it out step by step, and say plainly where our own prices sit.

This decision settles which contractor you choose — and whether you're comparing offers, or only the figure at the bottom of each one.

"We want to know how the project runs and what our part is"

An app project runs for months, but the client doesn't have to sit in on every meeting. They do have to be present at three moments: the brief, when what's being built gets settled; the prototype, when changing your mind costs less than at any other point in the project; and handover — acceptance testing — which can't be delegated to the contractor.

We describe how to build an app for your business with a contractor — from a one-page brief, through six project stages, to choosing a software house — together with how long it takes under the rules we use to plan projects, and what that time is spent on. In our estimates, programming is less than half the project.

This decision settles the schedule and your role in it — and whether you find out about a misunderstanding after two weeks, or after two months.

"Does the app have to be in a store?"

Many companies assume that "a phone app" means the App Store and Google Play. In fact, some of those needs can be met by a PWA — a website you can install on a phone, that works offline and sends notifications, without a store, without a review for every version and without account fees.

The limits of a PWA, though, are set by the phone's browser, not the contractor, and on iPhone they're narrower than on Android: installation is manual, notifications only work once the app's been added to the home screen, and some hardware features aren't there at all. We show what a PWA is, what it can do on each system, and when it replaces a store app, with a capability matrix checked against the original sources.

This decision settles the route to the user — and whether Apple and Google end up setting the second half of the project.

"We need an app in the App Store and Google Play"

If a store is what you need — because customers look for you there, because you need phone features or in-app payments — building the app is only half the work. The other half is set by the stores: a company account with a DUNS number, a test before launch, a review for every version, and requirements that change every year.

We describe how to make a mobile app for a business — from choosing a platform, through native and cross-platform apps, to the route to the store with the timelines Apple and Google publish — and why your own users matter more than the market average.

This decision settles which platform you start with, and how much time to add to your timeline before the app reaches users.

Business questions have their own section

This section assumes you know what you want to build, and you're asking how. If you first need to settle whether custom software is even worth it, go to our section on business software. That's where you'll find articles on when off-the-shelf software is enough, and when custom pays off, on low-code and no-code platforms, and on the systems companies most often start with: CRM for a small business, ERP systems and online booking systems.

Tools and data

Prices live in our reports, not in the articles, so we can update them in one place. Our web application cost report and mobile app cost report — our studies of the Polish market — bring together medians from offers and price lists, along with their methodology and its limits. Our web app cost calculator shows the difference between a first version and a full product for your own scope, and our quiz: website, web app or mobile app walks through the first decision on this map in a few questions.

When the app needs to talk to other systems — a bank, a shop, a courier or a public registry — the first concept worth understanding is API: what it is, how it differs from a webhook, and how to secure an integration.

When you're looking for a contractor

If the decisions are made and you're looking for a company to build the app, we describe how we work on web applications, mobile applications and MVPs for startups.