Websites
Marketing sites, content sites and landing pages built for speed, accessibility and search. A site with one job it does well, that your own team can edit.
Services
Mobile applications.
iOS and Android, for staff in the field and for customers. Native or cross-platform, chosen on what the app has to do rather than on which is cheaper to build.
Where this usually starts
Your people work away from a desk, on phones, sometimes with no signal, and the web application they were given does not survive that. Or you have a product that needs to be on a phone, and the parts that will cause trouble later — offline, sync, store review, updates — have not been discussed by anybody yet.
What this is
A mobile app carries obligations a website does not. It has to work when the network does not. It has to survive being suspended mid-task and resumed an hour later on a different network. It has to pass review by two companies with their own opinions and their own timetables, and then be updated on a schedule you do not fully control, on devices you cannot reach.
We build for both platforms, native or cross-platform. Most business applications — forms, lists, dashboards, messaging, moderate offline use — are well served by a cross-platform build sharing one codebase across both stores. Applications that lean hard on the camera, on background processing, on tight platform integration or on sustained graphics performance are usually better written natively. We will tell you which one yours is before you commit to either, and the answer is sometimes that you do not need an app at all.
How we approach it
What we think doing this well requires.
The accounts are yours
Apple and Google developer accounts are registered to you and stay with you. Firms that hold their clients' store accounts create a problem for those clients later, and we would rather not be part of that.
Offline is a design question, not a technical one
Which actions queue, which are refused, and how a conflict resolves are decisions about your business. We will raise them during design and make sure somebody with the authority to decide actually decides.
Release management is part of the job
Staged rollouts, forced upgrades when an API changes, and keeping the previous version working while people update. An app is not finished when it is submitted.
Respect the platform
Navigation, gestures, permission prompts and typography that match the operating system. An app that fights its platform feels wrong to use even when nobody can say precisely why.
Raised before the contract
The parts clients discover late.
None of these are unusual. All of them are cheaper to plan for than to discover, and raising them before a contract is signed is worth more to you than a feature list.
Offline behaviour and sync conflicts
What happens in a lift, a basement, or on hospital wifi. Which actions queue, which are refused outright, what the person sees while they wait — and what happens when two people edited the same thing on different phones. That last one has no default answer; it is a business decision and somebody has to make it.
App store review and rejection
Both stores can reject a release for reasons that are not in your plan, including on a second submission of something previously accepted. Schedules should have room for a rejection, and marketing dates should not be announced against a review queue.
Release management and forced upgrades
People do not update. When an API has to change, older versions in the wild still call it. That means versioned endpoints, a way to require an upgrade, and a message that explains it — all designed before the first release, not during the incident.
Device fragmentation
Small screens, old operating systems, aggressive battery managers that kill background work, and manufacturer variations that behave differently from the reference device. The test matrix is agreed early because it has a cost.
What maintenance actually costs
Both platforms change every year whether or not your app does. Certificates expire, SDKs are deprecated, store policies shift. An app with no maintenance budget becomes an app that stops working, and the time to plan for that is now.
| Consideration | Cross-platform | Native |
|---|---|---|
| Two stores, one codebase | Yes | No — two codebases |
| Forms, lists, dashboards, messaging | Well suited | Well suited |
| Heavy camera, sensor or background work | Possible, with native modules | Better |
| Sustained graphics or animation performance | Adequate for most | Better |
| Day-one support for a brand new OS feature | Usually waits | Immediate |
| Ongoing cost of maintaining both platforms | Lower | Higher |
What you get
Everything on this list is a deliverable, not an extra.
- Design for both platforms, respecting each one's conventions
- Source code in your repository
- Builds signed with certificates held in your own developer accounts
- Store listings prepared, submitted, and taken through review
- Offline and sync behaviour specified and tested, including the conflict cases
- Crash reporting, a release process and a documented upgrade path
- Handover, including how to ship the next version without us
Fit
Whether this is us.
Most unhappy projects were mis-scoped at the start rather than badly built. It costs nothing to be straight about this now, and it saves us both a call.
Best suited to
- Your people work away from a desk and the current tool assumes they do not
- The job needs the camera, notifications, or genuinely reliable offline use
- You already run a web application and need a companion for the field
- An internal app distributed to your own staff rather than through public stores
Probably not us if
- The content would be perfectly well served by a responsive website. An app wrapping a website buys you store review and update friction in exchange for very little, and we will say so before you spend the money
- The first release is scoped to everything at once. Both stores reward shipping something narrow and improving it, and we would rather argue about this now
- There is no budget or plan for maintenance after launch. The platforms will change regardless, and an unmaintained app is a slow, public failure
Related
Next to this.
Systems integration and modernisation
Two systems that do not talk, so somebody re-keys between them. Or an application that still works and nobody dares touch. Both are fixable without betting the business on a rewrite.
Healthcare software
Where this work goes deepest: claims and billing workflows, data exchange, reconciliation, audit trails and the formats healthcare actually runs on.
Tell us what you are trying to build.
Describe the problem in your own words. If we are not the right firm for it, we will say so.