It was scoped from a wish list
Every department contributed a feature, and the result does nine things adequately instead of one thing better than anything else on the phone. Nobody keeps an app for adequate.
iOS and Android applications built around a real use case, not a feature list — designed, developed, tested and shipped to the stores, with the UI/UX work included as part of the build.
Almost nobody deletes an app in anger. They install it, open it twice, and it quietly stops being one of the screens they visit. That is the failure worth designing against.
Every department contributed a feature, and the result does nine things adequately instead of one thing better than anything else on the phone. Nobody keeps an app for adequate.
A first install is easy to buy. A second open has to be earned by something the phone is uniquely good at — a task that repeats, a notification that matters, or work that continues where it stopped.
Fast phone, office wi-fi, a full test account. In the real world it meets a four-year-old handset on a weak signal, and the first review mentioning it costs more than the bug did.
Built directly for the platform when the product leans on what the device gives you — camera, location, background work, hardware or serious offline use. It costs more than one codebase, so we recommend it only when those things are load-bearing.
A single build serving both stores, which for most business applications is the same experience for less money and half the maintenance. We tell you which of the two you are looking at before the quote, not after.
The screens, the flows between them, and a component set they are all drawn from. This is not billed as design and then again as development: an app is a thing people touch, so the interface work is part of building it.
What the app holds on the device, what it fetches, and what it does when the connection drops mid-action. Settled early, because retrofitting an app that assumed a perfect network is close to a rewrite.
Sign-in, payments, notifications and your existing systems wired up; validated on actual handsets rather than a simulator; then submitted, reviewed and released — including the parts of store approval that catch first-time publishers.
Handed over at the end of the engagement, in a form your own team — or any other team — can build, sign and release without us.
The first deliverable is the recommendation, and sometimes it is that a responsive website would serve these people better for a fraction of the cost. You get that in writing, with the reasoning.
Who opens this, how often, to finish what — and the list of things version one deliberately does not do. Scope arguments six weeks in are usually arguments about a document nobody wrote.
Every screen drawn from one library of buttons, fields, states and spacing rules — so the app looks deliberate now, and the fifth screen your team adds still matches the first four.
Installable applications for the platforms agreed, and the repository they were built from — reviewable, buildable and yours from the first commit.
Sign-in, notifications, payments where relevant, and the connections to the systems already running the business — with access rules so an account reaches only what belongs to it.
App Store and Google Play entries prepared and submitted, the signing credentials in your name, and the build-and-release steps written down. The second release should not require us.
An app justifies itself through repeat use, not through existing. These are the four things that change when it is built around a use case rather than a feature list.
When the app does one job better than any other route to it, coming back is the path of least resistance rather than something a campaign has to keep buying.
Signed in, details remembered, two taps to done. The gap between that and filling the same form in a mobile browser is what makes people choose the app over the alternative.
A place on the home screen and permission to send a notification means an update arrives without an email being opened — provided it is worth sending, which is the harder part.
Both platforms change every year. An app on current frameworks with a documented build absorbs that as maintenance; one built quickly and left alone absorbs it as a crisis.
This is the Mobile Applications engagement specifically — not the general Novrix delivery process, which covers a whole project from discovery to launch.
Does the phone add something here that a browser cannot? If the answer is no, we say so and the engagement stops.
The one job the app exists to do, the platforms worth covering, and what version one leaves out on purpose.
Journeys and screens drawn to a thumb and a small screen, reviewed on a real handset before anything is coded.
Developed in installable slices — you run each one on your own phone rather than watching a screen recording.
Tested across real devices and weak connections, submitted to both stores, then improved on what usage shows.
Frequently not, and we would rather say so at the start than at the invoice. An app earns its cost when people use it repeatedly, or when it needs something a browser genuinely cannot reach — notifications, offline work, the camera, location, hardware. If your customers come a few times a year to do one thing, a fast responsive site will serve them better for a fraction of the price.
By what the product depends on, not by preference. Heavy device use, demanding graphics or serious offline behaviour point to native. Most business applications — booking, accounts, ordering, field reporting — get the same result from one cross-platform codebase for meaningfully less money to build and to keep running. The recommendation comes with its reasoning, so you can disagree with it.
That the journeys, the screens and the component set are part of this engagement and this price. There is no separate design phase to buy and no second invoice for making it look right. You can bring your own designers or an existing brand system and we will build to it — but if you do not have one, you are not being sold another project to get there.
Usually, and it is the cheaper route. If your bookings, stock or customer records already live somewhere that works, the app reads and writes there rather than keeping a second copy. Where an older system has no usable way in, we will say what it would take — and whether that is worth doing before the app rather than during it.
We do, on your developer accounts. That covers the listing, the screenshots, the privacy declarations and the review itself, which rejects a fair share of first submissions over things that have nothing to do with the code. The accounts stay in your name throughout — you are never publishing through us.
Yes, and it is often the sensible way in. One platform means a smaller first commitment and real usage before the second build. Which platform depends on where your customers actually are — a question your existing traffic can usually answer, so we look at that rather than guess.
Both platforms ship a major version every year, and store requirements move with them. An app left untouched will eventually stop being accepted for update, and later stop behaving properly on new handsets. We plan for that openly: current frameworks, a documented build, and a maintenance arrangement if you want one. It is a running cost, and it belongs in the budget from the start rather than arriving as a surprise.
You do — the source, the store accounts and the signing keys. Signing keys matter more than people expect: whoever holds them controls who can publish an update. They are issued in your name, and the handover is written so another team could take the next release without needing anything from us.
Describe what someone would open this for, and how often. We will tell you whether it needs an app, a website, or neither yet — before there is a proposal.