Services — 02
Mobile Applications
Applications that stay fast on mid-range devices, keep working when the connection drops, and sync cleanly when it returns. Built cross-platform so one team ships both stores.
The problem
A mobile product has to work on a four-year-old device, on a bad connection, in the hands of someone who will not read instructions. Most apps are built and tested in none of those conditions, which is why they feel fine in a demo and frustrating in the field.
How we approach it
Cross-platform from one codebase, so a feature ships to both stores at once rather than twice. We treat the device as the primary store and the server as eventual, which means the interface never blocks on the network and a lost connection is an inconvenience rather than a stoppage.
What changes
One codebase in both stores, work recorded at the point it happens, and a release process your team can run without us.
The things people ask before getting in touch.
If yours is not here, ask it directly — we would rather answer than have you guess.
Starting points are published on the pricing section of the home page, in the currency and rates that apply where you are — automation and internal tools at the low end, a first working version of a product in the middle, ongoing engineering as a monthly amount. Those are floors rather than quotes: what your project costs depends on scope, and we agree a fixed price against a written scope before you commit to anything. Everything is negotiable — if your budget is below them, say so and we will tell you honestly what is possible within it rather than pad the number or turn the conversation down.
A small automation or internal tool can be one to two weeks. A first working version of a product starts around four weeks and grows with scope — a larger platform is closer to three months. We break the work into short cycles with something usable at the end of each, so you are never waiting months to find out whether it is going the right way.
You do, completely, including the repository, the infrastructure configuration and the documentation. We hand over accounts in your name rather than ours. There is no licence, no lock-in, and nothing that stops another engineer picking it up.
That is a normal place to start and a good reason to talk early. Working out the right shape of a solution is the first thing we do anyway. Often the honest answer is that you need less software than you thought, or a different thing entirely, and we would rather tell you that than sell you the wrong build.
Your choice. We can hand over completely, stay on for a fixed monthly amount covering fixes, security updates and small changes, or return for defined pieces of work as you need them. Nothing is a locked contract, and nothing in the codebase depends on us staying.
Yes. Most of the work is remote regardless of location, and we are used to running projects across time zones with written updates and a running environment you can check any time rather than status meetings.
Often, yes. We start with a short review of the existing code and infrastructure and tell you honestly whether it is worth continuing or whether rebuilding a part of it will cost less than maintaining it. Inheriting a system is normal work, not a special case.
Tell us the number. A smaller budget usually means doing less rather than doing it worse — one workflow instead of five, one platform instead of two, the part that pays for itself first. We would rather scope something real to your budget than turn the conversation down or quietly cut corners to hit a figure.
Yes, before any detailed discussion if you prefer. We do not share client information, publish client names without permission, or use your project as a case study unless you have agreed to it.
Need mobile applications?
Tell us what you are dealing with. We will come back with how we would approach it, or tell you honestly if this is not the right fit.