Mobile apps, built as part of the platform
Most apps that get commissioned are the phone-shaped view of a system that also needs a website, an admin and a database. Building those separately is how projects double.
Start with the question that saves the most money
Does it need to be in an app store?
An app store listing buys you three things: a home-screen icon that people trust, push notifications, and access to hardware — camera, location, offline storage, biometrics. It costs you review cycles, two builds instead of one, store fees, and an update path where your users choose when to take your fix.
If you need those three things, build an app. If what you actually need is “our customers want to do this on their phone”, a well-built responsive web platform gets you there faster, cheaper, and without asking anyone to install anything.
We ask this question before quoting, and about half the time the answer changes the project.
What we build
Progressive web apps
Installable from the browser, with a home-screen icon, offline handling and push notifications where the platform supports them. One codebase, one deployment, no store review between you and a fix. This is the right answer more often than it is chosen.
Apps on top of an existing platform
Where you already have a web system — a portal, a store, a booking platform — and the app is the mobile face of it. The data model and the permissions already exist; the work is the interface and the offline behaviour.
The API behind the app
Whatever the front end turns out to be, something has to serve it. Authentication, accounts, permissions, data, notifications and versioning, built to be consumed by more than one client so the next thing you add is not another rebuild. See web development.
Platforms we build for
Named, because a page that lists capabilities without naming a stack is describing a service it does not run.
- Progressive web apps
- The default, and the right answer more often than it is chosen. Installable from the browser, offline handling, push notifications where the platform allows them. One codebase, no store review between you and a fix.
- React Native
- What we build store apps in. One codebase produces both an iOS and an Android build, it shares language and tooling with the web platform behind it, and it is the reason a store app does not cost twice a web one.
- Native Swift and Kotlin
- We do not build these in-house and we will say so at the first meeting rather than the third. If your app genuinely needs platform-native work — heavy graphics, deep hardware integration, background processing the frameworks will not do — that is a specialist and we will tell you to hire one.
- The API behind it
- Ours, in every case. Authentication, accounts, permissions, data and notifications, built to serve more than one client so the next thing you add is not another rebuild.
- Publishing
- App Store and Google Play submission is done inside your own developer account, in your company’s name, with the signing keys handed to you. We are the people who press the button, not the people who own the listing.
What an app costs you after launch
Worth knowing before you commit, because it is rarely in the quote:
- Apple and Google both change their requirements on their schedule. An app that is not updated is eventually removed.
- Developer programme fees are annual and are yours, not ours.
- Every fix goes through review, so “we can push that today” stops being true.
- Users on old versions are a category you will have to support.
None of these is a reason not to build an app. All of them are reasons to be sure you need one.
How an app project runs
- 01
Decide the shape. App store, progressive web app, or responsive web. Written down, with the reasoning, so the decision survives a change of stakeholder.
- 02
Scope. What version one does, on what devices, and what happens when there is no signal.
- 03
Build the API first. Whatever the interface, the data layer is the part everything else depends on.
- 04
Build the client. On real devices, from early on. Simulators hide the problems that matter.
- 05
Release and hand over. Store submission where relevant, plus the repository, the build instructions and the signing setup, so you are not locked to us to publish an update.
Questions we get asked
Do we need an app or a website?
Answered above, and it is the first thing we will ask. If the answer is a website, that is what we will quote for.
What does it cost?
We do not publish prices, because an app can be four weeks or six months and a number here would be a guess at your project rather than a price for it. What we do is scope it first, as a short paid piece of work, and quote a fixed price against that scope. You get the scope document either way, and you are free to take it elsewhere.
Can we start with a web version and add an app later?
Yes, and it is usually the cheaper route. Building the API first is what makes it possible.
Who owns the app listing?
You do. The developer account is yours, in your company’s name, and we work inside it. This matters more than it sounds — an app published under a supplier’s account is very difficult to move.
Who owns the code?
You do. Full repository, including the signing and build configuration.
Start a project
Tell us what people need to do on their phone and whether it has to be in a store.
Or email us at hello@felixwebsolutions.com.
Agency looking for a build partner? We work white-label →