01 Mobile app development
Apps people keep on the home screen.
We design and build native iOS and Android apps and cross-platform products in Flutter, from the first MVP through App Store review and the years of maintenance that decide whether an app survives. The same engineering discipline behind our software work, pointed at the device in someone's pocket.
02 The position
The hard part of an app is the second year.
Shipping version one is the easy half. Then iOS and Android change their rules underneath you, devices fragment, the App Store rejects a build the week of your launch, and the analytics nobody wired in mean you are guessing about what to fix. Most apps do not fail at launch. They quietly rot through the eighteen months after it, when the people who built them have already moved on.
We build for that horizon from day one. Architecture is decided deliberately and written down. State, navigation, and data layers are typed and tested so a small team can ship updates without re-breaking what already worked. We instrument the app so decisions are made on evidence, not vibes. And we are honest about platform choice, sometimes the right answer is a fast web app, not a native build, and we will tell you.
This is the same standard behind our custom software and web application engineering. Mobile is a harder distribution problem, not a lower bar.
03 Philosophy
We pick the platform for your users, not for our comfort.
There is no universally correct answer to native versus cross-platform, and any shop that gives you one without asking about your product is selling, not advising. Native earns its cost when you live at the edge of the hardware, deep camera work, heavy graphics, tight OS integration. Flutter earns its cost when one team shipping to both platforms fast matters more than squeezing the last few per cent of platform feel.
Boutique means the engineer who scopes that decision is the engineer who builds it. You will not be sold a senior architect and handed a junior delivery team. The person reasoning about your App Store strategy in kickoff is the person in the codebase when a release needs to go out under pressure.
An app is not done when it ships. It is done when it has survived a year of OS updates and still feels fast.
04 Capabilities
What we actually build.
- 01
Native iOS
Swift and SwiftUI apps built to feel like they belong on the platform, with the OS-level integration and performance that only native delivers.
- 02
Native Android
Kotlin and Jetpack Compose apps engineered for the breadth of the Android device landscape, not just the one phone on a designer's desk.
- 03
Cross-platform with Flutter
One typed codebase shipping a consistent product to iOS and Android when speed to both stores outweighs platform-specific polish. The honest trade-offs are here.
- 04
MVP to App Store
Scoping the smallest honest version, building it, and steering it through App Store and Play Store review, the part most teams underestimate until the rejection email lands.
- 05
Backends & APIs
The services an app actually runs on, auth, sync, push, and well-designed APIs, often shared with a companion web application so one backend serves every surface.
- 06
Maintenance & evolution
The long game, OS-version upgrades, dependency hygiene, performance budgets, and the steady release cadence that keeps an app alive instead of abandoned.
05 Method
How we think about the work.
- 01
Decide native vs cross-platform on evidence.
We start from your users, your hardware needs, and your release tempo, then choose. The platform decision is architectural, and getting it wrong is expensive to unwind once you have a codebase.
- 02
Instrument before you optimise.
An app you cannot measure is an app you are guessing about. We wire in analytics, crash reporting, and performance tracing from the start so every later decision rests on what users actually do.
- 03
Ship a cadence, not a launch.
We design for the release after the release. The measure of the work is whether your team can keep shipping confidently long after the first version is live and we have gone.
07 Related thinking
Where this work goes deeper.
· Questions we get
Common questions, honest answers.
-
Should we build native or cross-platform?
It depends on the product, and we will give you a real recommendation rather than a default. Native (Swift or Kotlin) wins when you need deep hardware access, heavy graphics, or platform-perfect feel. Flutter wins when one team shipping to both platforms quickly matters more than squeezing out the last few per cent of native polish. We have written up the full trade-offs in our insight on Flutter versus native.
-
Can you take an app all the way through App Store approval?
Yes. We handle the build, the store-listing technicals, and the submission and review process for both the App Store and Google Play, including the resubmissions that real launches usually require. Apple's review in particular has rules that are easy to trip over, and we have been through it many times.
-
How much does a mobile app cost to build?
Engagements start at $2,500 for a focused audit or sprint; a full native or cross-platform app with a custom backend is scoped on the call. We take a limited number of clients each year, so the people who scope your app are the people who build and maintain it, no handoff to a junior team after the contract is signed.
-
Do you maintain apps after launch, or just build them?
We strongly prefer to stay. An app left unmaintained breaks within a year as iOS and Android evolve. Most of our mobile engagements include an ongoing maintenance arrangement, OS-version upgrades, dependency updates, and a steady release cadence, because that is where an app's real lifetime value is won or lost.
· Working together
Tell us about the app you want to ship.
If it is worth shipping to a million pockets, it is worth a real conversation first. We will tell you honestly which platform fits, whether native or Flutter is right, and whether we are the team to build it.
Start a conversation