Generative AI App Development
Apps built around generative AI, or existing apps gaining features like writing help or summaries. For each feature we choose the model and where it runs, then build the product around it.
Why add generative AI?
Less typing
People describe what they want in their own words and the app drafts it, from a short message to a full product listing.
Speaks their language
The same feature works in each of the languages your customers speak.
The right model
Each feature gets the model that fits its cost and quality needs, whether that’s a large one like Claude or ChatGPT or a small one on the phone.
Within limits
Instructions and checks keep answers on topic and stop the feature from saying things your business wouldn’t want said in its name.
Costs in view
Usage is measured from the first day, so you know what each feature costs to run long before the bill grows.
Ready for better models
Models improve quickly, so the app is built to swap in a better one later without rebuilding the feature or the screens around it.
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.
