App Development
Mobile apps that feel like they belong on the phone
People can tell within about ten seconds whether an app was built properly. Scrolling that stutters, buttons in the wrong place, a spinner where there should be content. I build apps that pass that test, and I handle the unglamorous parts too; store submission, updates, and the OS releases that arrive every autumn whether you're ready or not.
An app is worth building when the phone is genuinely the right place for the work - when your users are out on site, on the move, or need to do something in thirty seconds while standing up. If people are sat at a desk, a good web app is usually cheaper and better, and I'll tell you that rather than sell you an app you don't need.
When mobile is the right answer, the build is only part of it. An app has to work when the signal drops, has to send notifications people actually act on, and has to get through App Store review, which has rules that aren't always obvious until you've been rejected by them. I've done that side of it enough times to route around most of it.
The clearest example I've got is Knights Events. They supply crew nationwide to build festival stages and expos, and their entire job-offering process ran on individual phone calls and emails, burning around four hours a day. The app replaced it: push a job out, crew accept or decline instantly, everyone sees where they're going. That's roughly £5,000 a month in staff time they got back.
iOS & Android builds
Apps for both platforms, or one first if that's the sensible way to start. Cross-platform where it saves you money without costing you quality, fully native where the app genuinely needs it. I'll explain which one yours is and why, rather than defaulting to whatever I feel like writing.
Offline-first architecture
Phones lose signal. Warehouses, festival sites, basements, trains. If your users work in those places, the app has to keep working and sync up cleanly when the connection comes back, rather than throwing an error and losing what they just typed.
Push notifications that get acted on
The difference between a notification people respond to and one they swipe away is mostly timing and relevance. Getting this right is what made the Knights Events app work: crew accept jobs the moment they land, with no back-and-forth needed at all.
Backends & APIs
Most apps are only the visible half. Behind them sits an API, a database, and an admin side for your team to actually run things. I build that too, so there's no gap between the app and the system it depends on, and nobody to blame it on.
Store submission & release
Getting through App Store and Play Store review, set up under your own developer accounts rather than mine. Then the release process afterwards: staged rollouts, over-the-air updates for the things that don't need a full review cycle, and keeping up with each new OS version.
Taking on an existing app
An app that shipped and then stalled, or one whose original developer has moved on. I'll read the codebase, tell you honestly what state it's in, and take over maintenance and new features from there. No rebuild unless it genuinely needs one.
Scope
We work out what the app actually needs to do, and just as importantly what it doesn't need to do in version one. This is also where I'll tell you if a mobile app is the wrong tool for your problem, before you've spent anything.
Build & test on real devices
Phased delivery with agreed milestones, tested on actual hardware rather than only a simulator, because that's where the awkward bugs live. You'll have something in your hands to try well before launch.
Ship & keep it current
Store submission, launch, and then the ongoing work: OS updates, new features, and fixes. An app is never really finished, so someone needs to own it. That's usually me.
Knights Events supply crew across the country for festival stages and expos. Administrative staff were phoning and emailing crew individually to check availability and offer work, losing around four hours every day to it. The app made the whole process asynchronous: crew get notified, accept or decline instantly, and see exactly where they need to be.
Read the Knights Events case study →Do I need both iOS and Android, or can I start with one?+
It depends entirely on who your users are. If it's an internal app and your team is all on company iPhones, build for iOS and save the money. If it's consumer-facing in the UK, you'll want both eventually, though starting with one to prove the idea is often the smarter move. Cross-platform means the second one costs far less than the first, so this decision is less final than it feels.
Cross-platform or fully native — which do I need?+
Cross-platform for the large majority of apps, and it isn't a compromise the way it was a few years ago. One codebase, both platforms, and users can't tell. Fully native earns its extra cost when you're leaning hard on device hardware, doing heavy real-time graphics, or need something the moment a new OS ships. I'll tell you which camp yours is in during scoping rather than after you've paid for the wrong one.
How long does an app take to build?+
A focused app doing one job well is usually a couple of months. Something with a backend, an admin system, and several user types takes longer. One thing worth knowing, store review adds time at the end that's outside anyone's control, usually days rather than weeks, and I'll build that into the timeline rather than surprise you with it.
What does an app cost?+
The honest answer is that it depends on scope, and the biggest drivers are how many user types the app has to serve, whether it needs a backend built from scratch or can talk to something you already own, and whether you need both platforms at launch. I'll give you a real number with the risks flagged before you commit. App development is an investment, and i'll ensure you've got the facts and figures to make a decision as early as possible.
Who owns the App Store and Play Store accounts?+
You do. I'll set them up in your business's name and get you through verification, and I work under your accounts rather than publishing your app under mine. It's a small detail that becomes a serious problem later if someone gets it wrong; apps effectively held hostage by a former developer's account is a situation I've seen more than once.
Will the app work without an internet connection?+
If your users need it to, yes, and it's worth designing in from the start rather than retrofitting. The app stores data locally, lets people carry on working, and syncs when the connection returns. For anyone working on site, in warehouses, or out in the field, this is usually the difference between an app that gets used and one that gets abandoned.
What happens when Apple or Google release a new OS version?+
Something usually needs adjusting, every year, whether that's a visual change or a deprecated API. This is exactly why apps need an owner rather than a handover. If I'm looking after your app, I'll test against the new versions and sort out what needs sorting, generally before your users notice anything.
Do we need a backend as well as the app?+
Almost always, unless the app genuinely only works with data on the phone itself. Anything involving accounts, syncing between users, notifications, or your team seeing what's going on needs something behind it. I build both, so you're not coordinating between an app developer and a separate backend developer who each think the other's handling it.
Can you take over an app someone else built?+
Yes. I'll go through the codebase and give you a straight read on its condition, what it would take to maintain, and whether any of it needs replacing. Plenty of apps are in decent shape and just need someone to own them again. If yours genuinely needs rebuilding I'll say so, but that's not my default answer.