On-device AI
AI that runs on the phone rather than on someone’s server. It suits features that must work offline or keep data private, and we decide feature by feature whether the device or the cloud fits better.
Why run AI on the device?
Data stays put
What people type, say or photograph can be processed without leaving their phone, which keeps privacy simple to explain.
Works anywhere
The feature keeps working on a plane or wherever the signal drops, because nothing it does has to reach a server.
No cost per use
Once it ships there’s no bill for each request, so a feature that becomes popular never turns into an expensive one.
Quick responses
With no round trip to a server, results come back fast, even for the features people reach for many times a day.
Live camera and voice
It suits features that react to every frame or word, such as scanning or live transcription.
Cloud when it fits
Not every task belongs on a phone. Larger ones can still go to a cloud model, and we decide which way each feature goes.
Our Process
We create in circles. Ask, listen, think, create, then ask again with better questions than the first time.
- (01)
Ask
The opening questions are about your business and your customers, not about software.
Start the process - (02)
Listen
Much of the answer already exists inside your company, and finding it is most of the job.
Collect the data - (03)
Think
Options are weighed against cost and time, and you see the reasoning, not just a verdict.
Decide what to do - (04)
Create
Then it gets built, and what you learn from real use decides where the next round goes.
Work on it
Why us
How we work on every project.
Direct line
The developer writing your code is the one answering your messages. Nobody relays them, so questions go straight to the person who knows.
Plain answers
Before you spend anything on the build, you hear what’s wrong and what it will take, including the parts nobody likes hearing. We’d rather say it then than halfway through.
Side by side
Your own developers work alongside ours before we step back. By the time we leave, the code is theirs and they know their way around it.
Plan first
Scope and designs are agreed before any code is written. If the plan has to change halfway, we agree the change and what it affects with you before carrying on.
Tools per job
No stack is presumed on our side. Each project starts from what the product needs, and the tools follow from that.
After launch
Once it’s live, staying on is your call. Ongoing fixes and monitoring are there if you want them, and if you’d rather take it from there, the exit is clean.
Discover More Services
Other kinds of work we take on, across the four groups.
Tech we use on repeat
These come up on project after project. Each project picks the ones its product needs.
We develop for
Everything we build runs on at least one of these three. On phones, a single codebase usually covers both Android and iOS.
Web
Web apps people sign in to, and company websites too. Pages load quickly and are built to be found in search, on any screen size. Where there’s also a phone app, the web version shares much of its code.
Android
Built from the same code as the iPhone app, then tested across Android phones, older and cheaper ones included. The back button and notifications behave as Android users expect, and we publish it on Google Play.
iOS
The same codebase as the Android app, shaped so it feels like an iPhone app in its gestures and layout. Widgets, Apple Pay or Face ID come in when the product needs them, and we steer it through Apple’s review.
