App development agency · iOS, Android and the backend behind them An app is a product, not a project

Most apps are abandoned somewhere between the idea and the second release

Mobile app development goes wrong in a pattern. The first version is quoted, built and launched. Then the founder discovers that an app is not a thing you finish. The store rejects an update. Apple changes a rule. A user reports a bug nobody can reproduce. The agency that built it has moved on, the code is in a repository nobody can access, and the second release never happens.

That is not a design failure or a code failure. It is a decision failure. Nobody settled who owns the accounts, who ships the next version, and what the app is for once the launch excitement has gone.

We build mobile apps the way we run everything else here: in house, month to month, with the accounts in your name from the first day. Custom mobile app development, done by the people you actually speak to.

What we have actually shipped

Three of our apps are live right now. Two are on Google Play, published by AMW Media Ltd, one is on the App Store, and two more are with Apple for review.

• MyContentLab. Our own reporting platform as an Android app, live on 27 October 2026. Social, ad accounts, Google properties and the CRM in one view. The iOS version is in Apple review. The case study is here.
• D16. A private members app for a motorcycle club: rides, routes, voice on the move, a shop and an invite only member area, live on 29 October 2026, iOS in review. The case study is here.
• AI Limits. A widget showing the usage limits of AI tools, live on the App Store since 31 October 2026, with Mac, Android and Windows builds behind it. The case study is here.
• PLOX. Brand identity, phone interface and website for a new consumer technology company. The design story is here.
• FitConnect. A fitness app build. The case study is here.

That is five mobile and web apps from one in house team, four of them in the last two months, built for Android and iOS. We are not a mobile app development company that subcontracts the build to an offshore studio and manages the email. The people who design your app are the people who write it.

What kind of app are we talking about

Mobile app development covers four different jobs and they cost different amounts. Knowing which one you are buying is most of the conversation.

• A customer app. Your customers install it and come back to it: booking, accounts, orders, loyalty, a service they use weekly. It has to earn its place on a home screen against everything else on the phone.
• A membership or community app. People, roles, private content, events, messaging. The hard part is not the screens, it is making sure the right member sees the right thing, every time, enforced in the database rather than hidden in the interface.
• An internal tool. Your own team, out on site or on the shop floor, doing the thing that is currently a paper form or a WhatsApp message. These are the mobile applications that pay for themselves fastest and nobody puts them in a portfolio.
• A web app. No store at all. It runs in a browser, it updates the moment you publish, and for a lot of business software it is the correct answer. Our own reporting platform started this way.

Most projects turn out to be two of these. A customer app usually needs an admin panel, and an internal tool usually needs a web app behind it. We would rather find that out in the first week than the eighth.

Native, cross platform or a web app

There are three honest answers to this and an app development agency that gives you the same one every time is selling what it is set up to build.

• Cross platform apps. One codebase, iOS and Android, one team. For most businesses this is the right call: you get both platforms for close to the cost of one, and the parts a user notices are indistinguishable from native apps. This is what we build by default.
• Native apps. Separate builds for each platform. Worth it when the app lives or dies on something only the platform can do well: heavy graphics, deep camera work, complex background behaviour, watch and widget work that has to feel perfect.
• A progressive web app. No store, no review, installs from a browser. Cheapest and fastest. The right answer more often than agencies admit, and the wrong one if you need push notifications to work properly on iPhone or you want to be found in the stores.

We will tell you which of the three your idea needs on the first call, including when the answer is that you do not need an app at all. That is the difference between bespoke app developers and a shop with one way of building things.

What we build on

React Native and Expo for the apps, so iOS and Android come from one codebase. Supabase for the database, authentication and the server side functions. Next.js on Vercel for the web app and the marketing site. Everything connects to the same backend, so the app, the website and the admin panel never disagree about what a customer did.

For the parts that matter we do the unglamorous work properly: row level security on every table so one member cannot read another member’s data, real quality assurance before a build goes to the stores, and a release process that means an update takes days rather than a renegotiation.

The technology stack, and why

React Native with Expo for cross platform app development, because one codebase covering Android and iOS halves the work and, on the screens people actually use, nobody can tell. Where a platform needs something only it can do, we write that part natively and share everything underneath, which is how our own four platform utility is built.

Supabase for the database, authentication and server side functions. Next.js on Vercel for web development: the marketing site, the web app and the admin panel. One backend behind all of it, so the phone app and the website never disagree.

We also work on existing apps. If you have an app that someone else built and abandoned, we will read it honestly and tell you whether it is worth continuing or whether a rebuild costs less than the archaeology. Sometimes the answer is the one that loses us the bigger job.

Design comes before code

UI and UX design comes first: every screen is designed in your brand and signed off before anything is built. Not a wireframe, not a mood board: the actual screens, in the actual colours, with the actual words on the buttons.

It is the cheapest hour in the project. Moving a button in a design file takes a minute. Moving it after the screen is built, tested and submitted takes a day and a resubmission. Good UI and UX design is mostly the discipline of making those decisions while they are still cheap.

We design for the phone first, in daylight, with one hand. Not for a large monitor in a dark room, which is where most app design goes wrong.

How a build runs

Listen, strategise, create, measure. The same four steps as everything else we do, applied to software.

• Scope. What a user must be able to do, in order of importance. The list that does not make the first release is as valuable as the list that does.
• UI and UX design. Every screen designed in your brand before a line of code is written, so you are approving an app rather than imagining one.
• Build. Working versions on your own phone throughout, not a demo at the end. You use it while it is being made.
• Stores. We prepare the listings, the screenshots, the privacy declarations and the review submissions. Apple and Google both reject first attempts for reasons that are not obvious. We have been through it this month.
• After launch. Ongoing support and maintenance, bug fixes, the operating system updates that arrive every autumn, and the second release. The part most projects never reach.

Testing, and the bit everyone skips

Quality assurance on multiple platforms is not one job done twice. An app behaves differently on a three year old Android handset than it does on a new iPhone, and both of those behave differently again when the signal drops halfway through something.

We test on real devices, not only simulators, and we write tests for the parts where a bug is expensive rather than embarrassing: payments, permissions, anything that decides who can see what.

Apple and Google both review every submission and both reject things that look fine to you. Privacy declarations, sign in requirements, what your screenshots show, how you describe what the app collects. We prepare that paperwork as part of the build because it is the difference between shipping this month and shipping next month.

What to ask any app development agency before you sign

Ask us these too. If an answer is vague, that is the answer.

• Who actually writes it? Plenty of UK app developers subcontract the build and keep the client relationship. Ask who the mobile app developers are, where they sit, and whether you can speak to them.
• What is the development process, week by week? You should get working builds on your own phone throughout, not a demo at the end. Ask when the first one lands.
• Who owns the code and the accounts? The repository, the Apple and Google developer accounts, the database. If the answer is not “you”, walk away.
• What does post launch support cost, and what does it cover? Ongoing maintenance is not optional on a phone app. Get the number before you commit, not after the warranty runs out.
• What is in the first release, and what is not? A quote without that list is not a quote.
• Which technology stack, and why that one? Any experienced team can explain the choice in plain words. If you get a brochure instead, that is a sign.

Most app development services in the UK are sold on a portfolio and a process diagram. The two things that actually predict whether you will be happy in a year are who writes the code and who owns it at the end.

What a mobile app costs in the UK

Mobile app development cost is the question everybody asks and almost nobody answers. The agencies on page one of Google quote £10,000 to £25,000 for a basic mobile app and £25,000 to £70,000 for a mid level one, usually after a form and two calls.

Our app builds start at £7,500. That is a real app on both platforms, designed, built, tested and submitted to the stores, with the backend behind it. Bespoke mobile app development at a price a small business can actually reach.

What moves the number: how many screens, whether it needs payments, whether it has to talk to software you already run, whether there are user accounts and roles, and whether you need the web app as well as the phone app. We scope it properly and tell you before you commit, and the rate card for everything else we do is published too.

What moves the price

• How many screens, and how different they are. Twenty screens that are variations of a list cost less than six screens that each do something new.
• Accounts and roles. An app where everyone sees the same thing is a different build from one where a manager sees more than a member.
• Payments. Taking money brings rules, both the law and the app stores, and Apple has its own opinion about what you may charge for inside an app.
• Integrations. Anything that has to talk to software you already run: a CRM, a booking system, stock, accounting. Integrations found late are what break budgets.
• Offline. An app that must work without signal is a harder build than one that assumes a connection, and it is worth saying so at the start.

We quote the build after scoping it, not before, and the quote says what is in the first release and what is not.

What you own at the end

The code, the repository, the Apple and Google developer accounts, the database and the domain. All in your name, all handed over documented. If you want to take the app to another development company next year, you can, and nothing of yours is held hostage to make leaving difficult.

There is no long term contract on the maintenance either. It is month to month, like everything else here.

After launch

An app that nobody maintains stops working in about a year. Apple and Google both ship a new operating system every autumn, both change their rules, and both will eventually refuse to serve an app that has not been rebuilt against the current tools.

Ongoing support and maintenance covers the operating system updates, bug fixes, store resubmissions and the small improvements that come out of people actually using it. Month to month, no long term contract, cancel when you like. That is the same arrangement as everything else we do.

The second release is where an app gets good. The first one is a guess informed by research. The second is informed by what people did.

When not to build an app

If your customers would use it once, build a website. If you want people to buy something, a good mobile website usually beats an app, because nobody downloads an app to make one purchase. If the whole idea is a form, it is a form.

An app earns its place when people come back: a membership, a tool that fits your business operations and your team uses every day, a product that has to work without signal, something that needs the phone itself. That is where user engagement is real rather than hoped for. Those are the ones worth paying for.

Who this is for

We are a small in house team working with UK businesses, not a software development company with three hundred people and an account manager between you and the work. That shapes what we are good at.

A good fit: a business with a real operational problem, a club or membership that has outgrown spreadsheets and group chats, a product company that needs its first app to be right, or a team that wants the website, the app, the brand and the marketing coming from the same place rather than four suppliers blaming each other.

A bad fit: a fifty person enterprise rollout with a procurement process, or an idea that needs a million users before it makes sense. We will say so on the first call rather than take the brief.