Mobile apps
iOS and Android apps built from one codebase in Flutter, connected to the systems you already run: your bookings, your customer records, your payments.
An app makes sense when your clients or your staff do something on a phone often enough that a mobile website gets in the way. A protected client area is the obvious example: a fund's investors or a law firm's clients checking their holdings or where their matter stands, being told when a new statement is ready, signing a document, or sending in the ID for onboarding with the phone's camera. The same goes for a travel or events company's customers, checking a booking, showing a ticket at the door or paying a balance.
An app used to be a separate project with its own budget, twice, once for each platform. Flutter means one build and one set of updates for both, and because I build the systems behind it as well, the app and the backend are one project rather than two.
One I've built
For Party Hard Travel, a company handling tens of thousands of bookings a season, I built the travellers' app: itineraries and venue maps, upgrades and add-ons, digital tickets, push notifications for payments and events, group bookings with friends, photo galleries, and a way to reach a resort rep in an emergency. It shares its backend with the booking system and admin area. Read the case study.
What's involved
One codebase that compiles to native apps on both platforms, with proper access to the camera, notifications and location, so it feels like an app rather than a website in a frame. It connects to whatever you already run, or I build the backend as part of the same project. App Store and Google Play submission, certificates and updates are handled.
Do you need one?
Often not. A well-built mobile website does most jobs, and it's cheaper to run. An app earns its place when people use it repeatedly, when you need notifications, tickets or the camera, or when it has to work with a poor signal. If a mobile site would do, I'll say so.