Native, cross-platform or web app: the three big choices
Every app idea ends up at the same fork. You can build it natively, build it once for both phones, or build it for the browser. Each is a proper answer. Each is also the wrong answer for somebody.
Native means writing separate apps for each phone: Swift for iPhone and iPad, Kotlin for Android. You get the best feel and first access to whatever the phone can do, from the camera to Face ID to Bluetooth. You also pay for two apps.
Cross-platform means one codebase that runs on both. React Native (built on JavaScript and React) and Flutter (built on Dart) are the two big names. One team and one set of features. Most apps feel native enough that users never notice. A few, the ones that lean hard on the phone's guts, still do better going fully native.
A progressive web app, or PWA, is a website that behaves like an app: it can be added to the home screen, cope with a patchy connection and send notifications. Nobody has to visit an app store. The trade-off is that the phone gives it less room to play than it gives a native app.
What sits behind the app: the back end
The app is the part people see. The back end is the part that remembers things: accounts, bookings, orders, payments. It runs on a server, usually in the cloud, and the app talks to it. It can be updated without asking anyone to download anything, and a good one can serve an iPhone app, an Android app and a website all at once.
Node.js is popular because it uses JavaScript, so a small team can share skills between the app and the server. Python is a strong all-rounder and a natural fit when data, reporting or machine learning are in the mix. Go is built for fast, steady services that handle a lot at once. Behind all three sit cloud services for hosting, databases, file storage and sign-in, so you rent the heavy lifting instead of building it.
Imagine a neighbourhood food-delivery start-up in Hackney
The idea: you want to bring food from independent restaurants to the streets around you, faster and fairer than the big apps. Customers order. Restaurants accept. Riders collect and deliver, and everyone can watch the dot move on the map.
What we would build it with: a cross-platform app, React Native or Flutter, for customers, and a lighter one for riders. You need an iPhone and an Android version from day one, because your riders will not all own the same phone, and you cannot afford to build everything twice while you are still learning what customers want.
Behind it, a Node back end on managed cloud services, with live location and push notifications handled by services built for the job. Background location is the rider app's main job, so test battery use on real phones first. If it is poor, that is the piece we would take native.
Imagine a clinic in Islington that wants bookings and reminders
The problem: a small private clinic is tired of phone tag. Patients should book online and get a text the day before. The receptionists should see the day at a glance.
What we would build it with: a progressive web app, not an app-store app. Patients book maybe twice a year. Few of them will download something for that, but nearly all of them will tap a link in a text message. A PWA opens straight away, works on almost any phone and keeps the whole project cheaper and quicker.
The back end would be Node or Python, with text and email reminders from an established messaging service. Health details are treated as especially sensitive under UK data protection law, so we would raise where the data is stored and who can see it on day one.
Imagine a Shoreditch fintech that has to be fast, safe and talk to banks
Picture an app that lets people see their money across accounts, move it and get paid. It must feel instant. It must never lose or double-count a penny. And it has to connect to UK banks, which usually means going through open banking connections.
What we would build it with: native apps, Swift on iPhone and Kotlin on Android, because for money, smoothness and trust matter more than saving on a second codebase. Native also gives you direct, first-class access to phone-level security such as Face ID and secure storage on the device.
The back end is where we would be strict: Go, split into small services, each doing one job well. Monzo has talked publicly about building on Go with microservices. For money, boring and reliable beats clever. Regulation is its own big topic, and you would want proper compliance advice alongside any developers.
Imagine a marketplace for local trades across London
This one has two sides: plumbers, electricians, roofers and decorators on one, homeowners and landlords on the other. A customer describes the job and gets a few quotes. A tradesperson sees nearby work and replies from a van.
What we would build it with: a web app first, built to be found. Plenty of people hunt for a plumber by searching Google at 7am with water on the floor, and a website can be found that way when an app in a store cannot. The tradespeople's side can start as a PWA with job alerts, both sides served by one Python or Node back end, with a payments provider doing the money part. If the trades begin to live in it all day, wrap it into a proper cross-platform app; the back end carries straight over.
How to choose your app stack without regretting it
Ask who is using it and where they are. People who live in the app every day, riders or traders, justify more effort. People who touch it twice a year want a link and no download. People who found you on Google want a website.
Then ask what the phone has to do. Plain forms, lists, maps and payments are fine for cross-platform or a PWA. Heavy background work, advanced Bluetooth, camera tricks or banking-grade security point towards native.
Then be honest about money and time. One codebase is usually the faster way to get something real in front of real people, and you can go native later where it counts. Plan for the long run as well. GOV.UK is a long-running public service built in the open, and a long life is worth designing for from the start.
Pick the simplest stack that does the job, then spend your effort on the people who will use it.