Release Process Optimisation
For teams whose releases are slow and nerve-racking. We set up a process that ships your app the same way every time, with checks along the way, so a release becomes routine.
Why fix how you release?
Ship more often
When releasing is routine, small improvements reach people steadily, instead of piling up for one big and nervous release.
Mistakes caught early
Automated tests run before every release, so the obvious mistakes are caught on the way out.
Rolled out gradually
A new version can go out to a small share of users first, and reach everyone else only once it has proved stable on their phones.
Easy to undo
If something does slip through, rolling back or shipping a fix is a practised step.
Stores handled
App Store review and Google Play publishing are built into the process.
Not one person’s job
Releases no longer depend on the one developer who remembers all the steps, because every step is now written into the process.
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.
