Mobile app development in Manchester
Matchday is the hardest load test a Manchester app will ever face. The city's football, live music and events businesses run apps that sit idle all week and then take their whole audience at once, in the same half hour, often on a stadium network that is barely working. Ticketing, entry passes, food orders and live updates all have to hold up in exactly those conditions.
We build in React Native for iOS and Android from one codebase, with offline behaviour designed in rather than bolted on: passes that open without a signal, orders that queue and send when the network returns, and a backend that expects a spike instead of hoping to avoid one. We load-test against the shape of a real event, and we tell you which parts degrade gracefully and which parts need someone watching on the day.
Manchester's software market has two centres of gravity, a tram ride apart. MediaCityUK in Salford is home to BBC North and ITV, and to the production companies, post houses and broadcast suppliers that grew up around them. Their systems are about media and rights: asset libraries, scheduling, metadata that has to follow a programme from edit to broadcast to streaming, and the comments, votes and uploads that now come with so many shows. Anything that hosts what the public posts needs moderation designed in from the first episode, because the busiest night is usually the launch.
The other centre is online retail. Greater Manchester is home to THG, boohoo, AO and Auto Trader, and that concentration has produced a generation of engineers and smaller brands who think in conversion rates, warehouse cut-offs and peak trading. The mid-sized retailers we hear from have usually outgrown their first platform in stages, and the joins between the shop, the warehouse and the finance system are where the money leaks. Between the broadcasters and the retailers sit the city's digital agencies, building for clients across the North and London, and they often need engineering capacity for a quarter rather than another permanent seat.
Hiring here is cheaper than London but not cheap. ITJobsWatch puts the median advertised salary for a software engineer in Manchester at £75,000 over the six months to September 2026, and GCHQ, which opened its Manchester site in 2019, now competes for the same security-minded engineers. Retailers and agencies feel the squeeze most in the run-up to peak, when a build has a fixed date and a permanent hire would arrive after it.
Working with us from Manchester fits the day you already have. Four hours of every working day overlap with yours, set across your morning, so stand-up, review and decisions happen live with the engineer who writes the code. The afternoon runs on pull requests and written updates in your own Slack, GitHub and Linear, waiting for you when you get back from lunch, with runbooks and architecture notes written as the work goes.
We are the right fit for a defined build, a deadline before peak, or a quarter of extra senior capacity for an agency that has won more work than it can staff. Start with a fixed-price two-week piece and judge us on the result. For agencies, we work white-label under your name, in your repositories and your tools.
Four ways this arrives.
And crashes on the ones your users own. We add crash reporting with readable stack traces, find the handful of devices and OS versions causing most of the crashes, and fix those before anyone touches a feature.
Signing keys on a laptop, a manual build, store notes written at midnight. We move builds and signing into CI, add over-the-air updates for JavaScript-only fixes, and write down exactly how a release goes out.
A Bluetooth device, a vendor SDK, a camera pipeline, a background task the OS keeps killing. We write the native module in Swift and Kotlin, expose a small typed interface to React Native, and keep it isolated so upgrades stay possible.
Forms that vanish, actions that send twice. We decide what must work offline, keep it on the device, queue writes with idempotency keys the backend understands, and show the user plainly what is still waiting to sync.
Our own React Native app on Android, with retraction built into the client because moderation can pull a message after it has been sent.
Read the write-up →Asked by Manchester teams.
How do you work with teams in Manchester?+
Four hours of every working day overlap with yours, set across your Manchester morning, so stand-up and review happen live. We join your calls and work in your tools: Slack, GitHub and Linear. You talk directly to the engineer who writes the code. When you get back from lunch, the afternoon's work is waiting in pull requests, with notes on what changed and why, and runbooks written as we go.
Do you build for Manchester retailers and media companies?+
Yes. For online retailers we build the joins that decide the margin: stock that is right across the website, marketplaces and warehouse, returns that flow back into sellable stock, and order data that reconciles with the 3PL and the payment provider. For broadcasters and suppliers at MediaCityUK we build content and rights metadata services, delivery APIs for streaming partners, and audience features with moderation designed in.
How does your rate compare to hiring in Manchester?+
ITJobsWatch puts the median advertised salary for a software engineer in Manchester at around £75,000. Our published rate is $35/hour with a $5,000 minimum, or $5,400 a month for one engineer embedded in your team. There is no recruiting time and no employment overhead, and we can start within days of the first call. A fixed-price two-week piece at $2,800 lets you judge us on output first.
Can you take over a platform a Manchester agency built?+
Yes. In Manchester a retail or media platform often outlives the agency that built it, so this is familiar work. After a 30-minute call with the engineer, we read the code, run it, and write down how it actually works: architecture notes, the risky paths and what we would change first. That becomes a written plan within a week. A fixed-price two-week piece then ships the first real change.
React Native or fully native?+
React Native for most products: one codebase, one team, both stores. Fully native makes sense when the app is mostly the hard native part, such as heavy camera or audio processing, complex background work, or a platform feature React Native does not support yet. We will tell you which side of that line you are on, and write the native parts by hand either way.
Expo or bare React Native?+
Expo, in almost every case now. Development builds and config plugins removed most of the old reasons to eject, and EAS handles builds and signing. We go bare only when a native dependency genuinely cannot live inside a config plugin, and we will explain why before doing it, because it makes every future upgrade more work.
Can you take over an app someone else built?+
Yes. We start by getting it to build on a clean machine, which is often the hardest step, then bring React Native and its dependencies up to a supported version before adding features. We tell you what state the app is in, including where the store listings, signing keys and accounts actually live, before quoting anything larger.
Who handles App Store and Play Store submission?+
We do, from your developer accounts, not ours. We prepare the builds, the privacy disclosures and the notes for the reviewer, and deal with rejections when they come. The accounts, signing keys and listings stay in your name, so you can change developers later without asking anyone's permission.
Does our backend need to change for a mobile app?+
Often, a little. A mobile client stays on old versions for months, retries on bad networks, and cannot be fixed by a server deploy. That means versioned endpoints, idempotent writes, and a way to tell an old client it must update. We check the backend for those before the first screen is built, because retrofitting them after launch is slower.