App Development
Mobile apps that your customers enjoy using
Nobody opens an app thinking about whether or not it was built properly, or the tools that were used to built it. They just expect the app to do what they use it for. The button should respond when they tap it, the list should reload when they try to refresh it, and parts of the app shouldn't randomly stop working after an update. We build apps with those expectations in mind, throughout the app development process. We handle the unglamorous parts too; store submission, updates and OS releases that arrive every quarter whether you're ready for them 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 with a customer. If people are sat at a desk, a good web app is usually cheaper and a much better solution, and we'll tell you that.
When mobile is the right answer, the build and what you actually see 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. We've done that side of it enough times to route around most of it.
The clearest example we'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. Their crew app replaced it; push a job out, crew accept or reject instantly, and everyone sees where they're going. That's roughly £5,000 a month in staff time they got back.
What we cover
iOS & Android builds
Apps for both platforms, or just one if that's what you need. Cross-platform where it saves you money without costing you quality, fully native where the app genuinely needs it. We'll explain which one yours is and why, rather than defaulting to whatever we feel like writing.
Offline-first architecture
Phones lose signal. Warehouses, festival sites, subways and trains. If your staff and customers 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 can 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/server, a database, and an admin side for your team to actually run things. We 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 the Apple App Store and Google Play Store review, set up under your own developer accounts rather than mine. Then the release process afterwards; staged rollouts, instant updates for the things that don't need a full review cycle, and keeping up with each new OS version as they land.
Taking on an existing app
An app that shipped and then stalled, or one whose original developer has moved on. We can handle it. We'll be able to tell you honestly what state it's in, and take over maintenance and new features from there. No rebuild unless it genuinely needs one.
How it works
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 we'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 the ongoing work; OS updates, new features, and fixes. An app is never really finished, it's always a work in progress, so someone needs to own it. That's usually us.
What's included
- iOS and/or Android, built to feel native
- Backend, API and admin built alongside the app
- Offline support where your users need it
- Published under your own developer accounts
- Tested on real devices before launch
- OS updates and new features after launch
Ways to work with us
No fixed packages, because every business is different - these are the shapes an engagement usually takes. We'll scope the detail, timeline, and cost with you before anything starts.
New app build
iOS, Android, or both.
- Native-feeling on every platform
- Backend and admin built too
- Published under your accounts
Ongoing partner
We keep it current.
- OS updates handled each year
- New features as you grow
- Staged rollouts and OTA updates
Take over an app
Adopt a stalled build.
- A straight read on its condition
- Maintenance and new features
- Rebuild only if it truly needs one
Proof
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 →Our work
See all work →
Frequently asked questions
Do I need both iOS and Android, or can I start with one?+
It depends entirely on who your end 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 or international, 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?+
We try to build all of our mobile applications cross-platform where possible. It saves you money in the long term and most application don't need the niche native only features. 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. We'll be able to tell you which camp yours falls into during initial project 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 nothing though is that the apple app store/google play store review adds time at the end that's outside anyone's control, usually days rather than weeks, and we'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 so many factors that it's impossible to give any pricing. An offline only application is going to be cheaper than an online app that syncs with your servers or existing databases. We're happy to quote for all app work, and we'll be able to give a rough ballpark figure after a short phone call or conversation. App development is an investment, and we'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. We'll do the initial set up in your business's name and get you through verification if you don't have them already, and we work under your accounts rather than publishing your app under ours. 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 we've seen more than once.
Will the app work without an internet connection or mobile signal?+
If your users need it to, yes, and it's worth designing it in from the start rather than retrofitting. The app can store data locally, allowing people to carry on working wherever they are, and then sync up again 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 quarter, whether that's a visual change or a deprecated API. This is exactly why apps need an owner rather than a handover. If we're looking after your app, we'll test against the new versions and sort out what needs sorting, generally before your users notice anything. This helps prevent costly bills every year or two when the app no longer supports the next major phone version.
Do we need a backend as well as the app?+
Almost always, unless the app genuinely only works with data on the phone itself (we refer to this as an offline app). Anything involving accounts, syncing between users, notifications, or your team seeing what's going on needs something behind it. We build both, so you're not coordinating between an app developer and a separate backend developer. It's much easier this way. We can also integrate with any existing systems you have if the integration is possible.
Can you take over an app someone else built?+
Yes. We'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, we'll say so however it's not very common to require this.