App design and development: what it actually involves and what it costs

In 2009, a taxi dispatcher in San Francisco named Travis Kalanick could not get a cab. He and a friend had been trying for twenty minutes. The idea that emerged from that frustration became Uber, within a decade, it had displaced an entire industry.

What is striking about that story, in retrospect, is not that someone built an app. It is that the app solved a specific, felt problem for a specific person in a specific moment. The technology was secondary. The problem was primary.

This is still the most important thing to understand about app development in 2026. Not which framework to use, not what it costs per screen, not whether to build for iOS or Android first. The important question is: what specific problem does the app solve that cannot be solved more simply some other way?

Most businesses that come to us asking for an app have not answered that question yet. And in most cases, when they do, the answer turns out to be: we do not actually need an app. We need a well-built web platform.

The distinction that matters

An app lives on a phone. To use it, a customer has to find it in an app store, download it, grant it permissions, create an account, and remember to open it again later. That is a significant amount of friction. It is worth paying if what you get on the other side of it justifies the cost.

The cases where it justifies the cost are specific. You need to send push notifications that users will actually open. Not email, push. You need offline functionality, because users will be in places without a reliable connection. You need access to native device features: the camera, GPS, biometric authentication, Bluetooth. Or the app itself is the product, something people will use every day, something that earns a place on their home screen.

If none of those apply, a progressive web application, a website built to behave like an app, is almost certainly the better answer. It loads in a browser. No download required. It works on every device. It can be added to the home screen. For staff tools, customer portals, booking systems, and internal dashboards, a well-built web application delivers everything a native app would and costs meaningfully less to build and maintain.

People remember the apps that changed their lives. They do not remember the ones they downloaded, opened twice, and deleted. The difference is almost always the answer to that original question: what specific problem does this solve?

What good app design actually involves

App design is not the same as web design. The screen is smaller. The input method is different, a finger, not a mouse. The context of use is different, someone is probably on the move, probably distracted, probably using the app in parallel with something else.

These constraints shape every design decision. Text has to be larger. Touch targets have to be bigger than you think. Navigation has to be immediately obvious without instruction. Every unnecessary step in a flow is a point at which someone will give up and do something else.

The best app design is invisible. The user accomplishes what they came to do without thinking about the interface. When it works, nobody notices. When it does not, everyone notices immediately. That is when you see it in your reviews.

Good app design starts long before any screen is drawn. It starts with the user journey: what does someone need to accomplish, what information do they need to do it, and in what sequence? Every screen that gets designed is the answer to a specific question about a specific step in that journey.

The three approaches to building an app

Native development means building separately for iOS and Android using each platform's own tools. Swift for Apple. Kotlin for Google. Native apps are the fastest and most capable. They are also the most expensive and slowest to build, because you are effectively building two apps, one for each platform, and maintaining them both indefinitely.

Cross-platform development using frameworks like React Native or Flutter lets you write most of the code once and deploy it to both platforms. Performance is close to native for the vast majority of business use cases. Cost is meaningfully lower. For most business applications, anything that is not doing something deeply platform-specific, this is the right approach.

Progressive web applications are websites engineered to behave like apps. They work in any browser, can be added to the home screen, and increasingly can access device features. For staff tools, customer portals, and operational dashboards, they are frequently the fastest path to a working product.

At Turtle Technologies, the recommendation we make is always the approach that gets the right product live fastest. Not the one that sounds the most impressive.

Which of the three you choose moves the price less than people expect. What moves it is whether the app has to work offline, whether it has accounts, and what else it has to stay in step with. We set that out, along with the yearly costs that come after launch, in how much an app costs and whether you need one.

That is what app design and development is for: deciding what the thing is before anybody builds it, then building the version that survives contact with a real phone in a real hand.

The best app in the world for a problem people do not actually have is worthless. The simplest app in the world for a problem people feel every day can change a business. Travis Kalanick did not design a beautiful app. He solved a real problem. The design came second.

The stages, and what each one produces

Every competent app project runs through the same six stages. The names vary between agencies; the decisions do not. What matters is that each stage produces something you can look at and disagree with before the next one starts, because changing your mind during stage two is cheap and changing it during stage five is not.

The stage people skip is the second one. Flow before visuals feels like a delay, and it is the only stage that prevents a rebuild. A beautiful screen that sits in the wrong place in a sequence is a wasted screen, and you only find out when somebody tries to use it.

Native, cross-platform or a web app

This is the decision that people argue about first and that matters least to a customer. All three can produce something excellent. What differs is cost, reach and how close you get to the hardware.

Our default recommendation for a business app that must exist on both platforms is cross-platform, and our default recommendation for a tool used by staff or account holders is a web app installed to the home screen. We recommend native when the app is the business, or when it depends on something the web genuinely cannot reach yet.

What drives the price

Nobody can price an app by the screen, and a figure quoted before scope is either a lie or a starting bid. These are the things that actually move the number, roughly in order of how much they move it.

Accounts, roles and permissions

An app where everyone sees the same thing is far simpler than one with customers, staff and managers seeing different things. Sign-in, password resets, verification, roles and the rules about who can do what is usually the largest single area of work, and it is invisible in a design.

How many systems it has to talk to

Each integration is a separate piece of engineering plus a separate thing that can fail: payments, a till, a booking system, an accounting package, a delivery provider. Two integrations is not twice the work of one, because they have to be reconciled with each other as well.

Whether it must work offline

Offline means the app holds its own copy of the data and reconciles it later, which means deciding what happens when two people changed the same thing on different phones. It is the most underestimated requirement in app development.

Payments and anything regulated

Taking money brings authentication rules, refunds, disputes and record-keeping. Handling health, financial or children’s data brings more. None of it is a reason not to build; all of it belongs in the quote rather than being discovered later.

Push notifications done properly

Sending a notification is simple. Deciding who gets which one, when, without becoming the app people mute, needs preferences, scheduling and a way to see what was sent. Notifications are usually the reason an app exists at all, so this is rarely the place to economise.

Content and data you already have

If a product list, a menu or a customer base has to be migrated, that is real work and it is where timelines slip. If it exists in a spreadsheet that nobody has tidied in three years, tidying it is part of the project whether or not anybody budgeted for it.

How long it takes

Most business apps we build are live in eight to sixteen weeks, and the range is about decisions rather than code. Here is where the time usually goes.

Designing to the platform, not against it

Both platform owners publish their design guidance, and both are worth reading before approving a design rather than after: Apple’s Human Interface Guidelines and Google’s Material Design. Accessibility has its own standard, the W3C’s WCAG 2.1, and meeting it is the same amount of work as missing it provided somebody decides at the start.

In practice this means a few specific things. Navigation sits where the platform puts it, so people do not have to learn your app. Tap targets are large enough to hit while walking. Type scales when somebody has set a larger size in their phone settings, which a surprising number of apps break. Colour contrast passes, labels are real labels rather than placeholder text, and nothing important is communicated by colour alone.

An app that ignores the platform conventions feels wrong in a way most people cannot name and all of them notice. It is also the commonest tell of a cheap cross-platform build: one layout, drawn once, shipped to both.

Getting it into the stores

The accounts should be in your name

The Apple and Google developer accounts, the signing certificates and the store listings belong to the business, not to the agency. If an agency holds them, moving away later means rebuilding a release process and sometimes republishing the app as a new listing, which loses its reviews and its install base. Ask about this before you sign anything.

Rejections are routine

Both stores review submissions. The usual reasons are mundane: missing privacy answers, a sign-in requirement without a guest path, placeholder content, or a feature a reviewer cannot reach. A rejection is a normal part of the first release rather than a sign anything has gone wrong, and it is usually resolved in the same week.

The listing is part of the product

The name, the subtitle, the screenshots and the first two lines of the description are what decide whether anyone installs it. They are also searchable inside the stores, which is a separate discipline from search on the web and worth a day of real attention rather than an afternoon.

What happens after launch

An app is not finished at release; it has an ongoing obligation attached to it. Both platforms ship a major operating system version every year, and both periodically change what a submitted app is required to do, which means an app nobody maintains will eventually stop being accepted or stop working on new devices.

The sensible minimum is crash reporting you actually read, analytics on the one journey that matters, and a budget for a release every few months. Beyond that, the useful question after eight weeks is not “what shall we add” but “where do people stop”, which the analytics answer and opinions do not.

The questions worth asking any app developer

Including us. The answers tell you more than a portfolio does.

“Which of my requirements would you argue me out of?”

Anybody who says none of them has not read the scope, or is pricing a wishlist they expect you to cut later.

“Who owns the code, the accounts and the data?”

You should, all three, in writing. This is the single question that decides how trapped you are in two years.

“Show me an app you built that I can install right now.”

A live listing, not a video. Then look at the reviews and the update history: an app last updated two years ago says something about what happened after launch.

“What happens when the operating system changes next autumn?”

There should be a plan and a price. “It will be fine” is not either of those.