Mobile Applications
Someone has told you that you should have an app. Maybe a competitor built one, maybe a customer mentioned it, maybe you have thought about it yourself — everyone is on their phone all day. But asked what the app would actually solve, the answer does not come easily.
the business is tied to a desk. Once the core system is stable, extending it into the field and into the customer's hands is what actually widens the touchpoints.
Choosing the wrong surface is expensive, because an app is not a website: two platforms to maintain, review processes, version updates — and above all, you have to persuade someone to install it. An app used twice a year does not stay on anyone's phone. Most “we should have an app” needs are met by a website that works well on a phone, at a fraction of the cost.
The root cause is treating “works on a phone” and “needs an app” as the same requirement. A mobile browser already handles most of it: ordering, booking, looking things up, paying, even notifications. The reasons that genuinely require a native app are few — camera, GPS, working offline, Bluetooth hardware, or usage frequent enough to earn a home-screen icon. Outside those, a website is cheaper, faster and far easier to find.
How the work runs
Confirm the phone is the right surface
Who uses it, where, how often, and what else is in their hands at the time. Someone working on site and someone at a desk need entirely different things. Sometimes the conclusion of this step is that what you need is a website that works properly on a phone.
Build only what gets used
A first version should feel almost uncomfortably small. The more an app does, the more likely it loses the user in the first minute. Do one thing well, then let usage decide what comes next.
Connect it to the systems you run
The app must not become a fifth copy of the data. It should read and write the same records your existing systems use — otherwise you have turned a four-places problem into a five-places one.
Count the store and the updates as cost
Developer accounts on two platforms, review time, and keeping up with OS releases are not surprises — they are the standing cost of an app. Stated before the build, not discovered after launch.
What changes for the business
- An honest answer on the surface
- App, mobile website, or neither — with the reasoning. This is frequently the answer that makes the project smaller for us.
- Usable where the work happens
- If it is for field staff, drivers or technicians, it has to work where the signal is bad, be usable one-handed, and have targets big enough to hit. Those are not details — they decide whether it gets used at all.
- One record, not another copy
- What the app shows and what the back office shows are the same record. No “the phone says in stock, the warehouse says otherwise”.
- Someone owns the store listing and the updates
- Submission, responding to review, and staying compatible with new OS versions can stay with us rather than leaving you to face two platforms alone after handover.
What's included
- Mobile App Development
- Customer-facing Apps
- Field Operations Apps
- Systems IntegrationSo app, website and core system share one set of data
Ongoing
Ongoing: releases, keeping up with OS updates, and iteration based on real usage.
This one is quoted individually
Website packages publish a floor because their scope is bounded. This does not, because the range is too wide for a figure to mean anything — a number in the middle deters the small project and over-promises on the large one. A free diagnostic settles the scope first, and the quotation follows from it.
See the published package prices, and why this is not one of themWhen this isn't the right thing yet
Not yet: building an app in order to have an app. If the core system is still shifting, the app will keep shifting with it.
Common questions
- Website or app — which should I build?
- Usually the website. The test is simple: if a user opens it fewer than a handful of times a month, they will not keep an icon for you. If it needs camera, GPS, offline working or Bluetooth hardware, or it is for staff who open it ten times a day, an app has a reason. We apply that test, including when it says no app.
- Do I need both iOS and Android?
- It depends on what your users carry. For an internal team, one platform is often enough because you supply the devices. For consumers, both — otherwise you are choosing to ignore half the market. We build with technology that can target both, but “can” and “worth it” are separate questions and get assessed separately.
- Could it be rejected by the app stores?
- Yes, and it is common — usually privacy disclosures, account deletion, or payment handling. The approach is to design to both platforms' rules during the build rather than fixing after submission. That time belongs in the schedule; assuming a first-time pass is how launch dates slip.
- Is there ongoing cost after launch?
- Yes, and this is where an app differs from a website, so it is worth deciding up front. Developer accounts are annual, the operating systems ship a release every year, and old approaches stop working. So our advice is plain: if you are not prepared to maintain it, do not build it. An app that has not been updated in two years and no longer opens does more damage than having none.