Native and cross-platform applications for phones and tablets, built for the conditions that only appear away from a desk — poor signal, a four-year-old device, and an app store sitting between you and your users.
A mobile application is a commitment to a release cycle you do not control. Two operating systems change every year, a review queue sits between a fix and the people who need it, and the phone in your customer's hand is probably older and slower than anything in your office. We build for that, and we will tell you plainly when a responsive website would serve you better than an app nobody downloads.
Each service page sets out the problem it addresses, how we approach it, the process, and what you receive at the end.
Native iPhone and iPad work that survives the annual OS release
Swift applications for iPhone and iPad, taken through App Review and maintained across Apple's yearly release cycle rather than abandoned at launch.
Built for the devices your users own, not the one on the demo stand
Kotlin applications for Android phones and tablets, tested across the screen sizes, OS versions and manufacturer behaviours your users actually have.
One codebase where that is honest, two where it is not
React Native and Flutter applications that serve iOS and Android from a shared codebase, with the platform-specific work identified and scoped rather than wished away.
The sectors these services are most often bought in. Knowing the vocabulary saves a week at the start; it does not tell us how your organisation works, and it is not an accreditation.
Public-facing sites, storefronts and browser-based applications built to be fast, findable and maintainable by people other than us.
Applications, platforms and integrations built for organisations whose process no longer fits anything they can buy off the shelf.
Research, flows, screens and component libraries produced against real content and real constraints, so that what is designed is what can actually be built.
Cloud environments, deployment pipelines, hosting and monitoring set up so that a release is boring, a restore has been tested, and somebody knows when it breaks.
Advisory work that ends in a decision you can act on — a costed plan, an architecture you can build against, or a prioritised list of what to fix first.
Keeping systems patched, monitored and understood after launch — with a named route to a person who knows how yours is built.
The project brief takes about five minutes and gives us enough to have a useful first conversation rather than a generic one. If you would rather just ask a question, the short form is there for that.
We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.