Monitoring & Observability
Seeing what your app is doing in the hands of real users, with crashes and slow screens reported as they happen. It’s part of every migration we run, and we also set it up on its own for apps that need it.
Why monitor your app?
Hear it first
You learn about a crash from your dashboard, before a customer has to tell you about it in a review or a support email.
Fix what matters
Problems arrive ranked by how many people they affect, so the team’s effort goes where it helps most, not where it’s loudest.
Real-world speed
Speed is measured on your users’ own phones and connections, which often tells a different story from the team’s.
End to end
Errors on your servers are tracked alongside the app’s own. One fault can be followed from the screen all the way to the server.
The full picture
Each error arrives with a record of what the person was doing at the time, which makes it quicker to reproduce and to fix properly.
Alerts worth reading
Alerts are tuned so the right person hears about a real problem quickly, and nobody is woken up at night by noise that can safely wait.
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.
