When a Business Should—and Should Not—Build a Mobile App

Your business needs a mobile app only if you can say how it makes or saves money, which recurring or device-specific job it makes easier on the phone, why the web can’t do that job well enough, and who will run it every year after launch. If you can’t answer all four, you don’t need an app yet. You need an answer.

Most app requests we get start from the wrong end. “Our competitors have one.” “Customers expect it.” “It would look good in the pitch.” None of those is a reason to spend a design and development budget, and none of them survives the first question we ask: how does this app pay for itself?

If the honest answer is that it would look impressive, Oksana, our founder, has a simpler suggestion: buy a Ferrari. It will look impressive too, and nobody will leave it a one-star review. The app budget should buy a useful product, not an expensive accessory.

ANODA starts where a feature-first brief usually stops: the business case, the real task and the friction customers face. We connect those decisions before design turns into a development bill. Pulse, Hike and Qarma below show how different jobs lead to different mobile experiences, rather than one copied app template.

First question: how does the app make or save money?

A business is a machine you feed a dollar and get more back. An app is a part of that machine or it is a white elephant: expensive to build, expensive to keep, and admired by nobody but the people who paid for it. There are only a few ways an app earns its keep:

• Direct revenue. People pay inside it: subscriptions, purchases, bookings.
• Indirect sales. The app makes something else sell: a device that works through it, a community that keeps owners loyal.
• Lower costs. It replaces a costlier channel: support calls, paper processes, paid traffic.
• Qualified leads. It turns interest into enquiries your sales team can close.

Whichever box you tick, it needs a number someone owns: enquiries per month, devices sold with the app, support calls avoided, paying subscribers. A subscription product has the plainest mechanism of all, and even there the question is not “will people pay” but “will they pay again next month for the job the app does”. If nobody can name the number, the box is a wish.

Saving counts as much as selling. A penny saved is a penny earned, and an app that takes calls off your support line never has to charge anyone a cent to be worth it.

Clearwater’s wellness app design connects Snowcap bath control, session tracking and community features. ANODA’s documented work covers the journeys, interface, design system, prototype and developer handoff. That combination gives the product a purpose beyond brand presence: help owners use the device and stay connected to the experience around it.

Clearwater used the app and its community to sell more devices and spend less on marketing. Money saved is money earned. If an app is just a beautiful accessory for your business, buy yourself a Ferrari instead. If you can’t explain how the app turns one dollar into five, goodbye.

Find the job people repeat, and where they are when they do it

Connect the business outcome to a task and its setting. Frequency matters for recurring work; a necessary device-specific task can justify an app even when it happens once. Study the actual context before choosing the format.

Infrequent use still creates maintenance costs, so weigh the task’s benefit against those costs. For a recurring task, consider this illustrative CRM scenario. Your salesperson is standing in a packed train at rush hour, holding the phone in one hand, trying to pinch-zoom a desktop table to find what time the next meeting is and who it is with. They are not going to open a laptop there. They need the next meeting, the context and a button to call.

ANODA adapts the journey to the job and chooses the right delivery format, rather than shrinking the desktop interface and hoping it works.

People are overloaded. An app that adds another thing to learn and maintain will be ignored, however polished it is. An app that takes a painful task off their plate gives them a reason to come back. ANODA designs for that useful moment, not a feature list that looks impressive in a pitch.

Describe the task before listing features. Make that moment easier and your product earns its place in the customer’s day.

Pulse: let drivers manage the service at the point of use

In Pulse’s car-wash app, the phone is where a driver chooses the vehicle and site, buys a wash, manages a subscription and starts a self-serve bay. The design connects those actions to the operator’s existing platform without exposing its back-office machinery. A failed code, timer or payment needs its own explanation, so the driver knows what to do next.

We designed 84 unique screens and mapped the flows for the client’s development team. For a business choosing its own app scope, this is a concrete starting point: take the recurring customer tasks that currently need staff and design them from selection through confirmation and recovery.

App, responsive website or PWA?

Before you commit to an app, check whether the web already does the job well enough. Often it does, and it does it without an install, a store review or a second codebase.

Observe where your audience performs the task today. Existing app habits can inform discovery, but they do not establish that your product needs the same format or that an app will be faster than the web.

For repeat jobs, test interruption and recovery rather than assuming the app format solves them. A web product can save drafts and support offline work; a native app can lose progress if those behaviours were never built. The useful comparison is whether each implementation preserves the task through a phone call, a lost connection and a return visit.

Design recovery into the chosen product, so an interruption does not turn useful work into another support request.

Web apps can use service workers and local storage for offline tasks and saved data. Notifications also depend on browser support, permission and background behaviour. For iOS distribution, Apple reviews submitted app versions and updates. Check the target devices and release path before budgeting the product.

The PWA sits in between and is worth a serious look when you need a home-screen presence without the full app bill. Just don’t choose between them by how the screens look; a PWA and an app can look identical. Choose by what the job needs from distribution, the device and the operating system.

Evaluate the capability in the actual setting

A device-specific task can make an app a strong candidate. Offline work on a site with no signal. GPS that places a report on the map. A camera that scans a serial plate instead of making someone type it. Bluetooth that pairs with the device you sell. Real-time updates, several sessions running at once, deep integration with the operating system.

Consider a field-reporting task that needs location, photos and draft recovery when connectivity is unavailable. This is an illustrative requirement, not a claim about a named client delivery. Test the relevant capabilities in both candidate implementations on the actual supported devices before deciding that an app is necessary.

Be honest about this list. Some of it works in a browser today, and the gap changes every year. The question is not “is it possible in a browser” but “is it reliable enough for our users, on their phones, where they actually work”. Test that before you decide. Plenty of apps still ship without offline mode where it is critical, which is the worst of both worlds: the full cost of an app and the failure mode of a web page.

Hike: the phone captures what an order needs

Hike’s employee app takes a person from an HR invitation through a plain-language form, pain questions, a guided LiDAR foot scan and an orthotics order. The scan journey includes checks and retries for the moments when permissions, positioning or capture go wrong. The employer’s roster belongs in the separate HR admin.

This is a different business case from a daily-use app: the phone earns its place through a specific capture task, even when the employee does not need to open it every day. We designed the brand, iOS app and HR admin; the app, scanning technology and insoles were built by others.

Installing isn’t using, and push isn’t a right

Map the path to the first useful task. For an app, that may include discovery, installation, opening, access and permissions. A website may also require sign-in and permissions, while an app may allow a useful task without an account. Identify where people stop in your actual flow before forecasting adoption.

A web product may also require discovery, access and permissions. Compare the actual paths; an app does not always need an account.

Remember who you are competing with for that home-screen spot. Not your direct competitor, but every app the user already opens daily. Yours has to be useful enough to be opened among them, not just downloaded and forgotten on page four.

Then there is the notification fantasy. “Once they install it, we can push to them.” You can ask. People are tired, they have been shouted at by every app on their phone, and many of them will say no. Build the business case so it still works for the people who tap “Don’t Allow”, because there will be a lot of them.

When you do ask, ask at a moment the user understands: after they requested something the notification will tell them about, with one clear promise and an easy “Not now”.

Put only the phone-shaped jobs on the phone

Copying a dense desktop interface onto a smaller screen can make an important task harder. Identify the records, actions and context a person needs on each device. Bulk editing, configuration and analysis may require a different composition or a larger surface; assess the task instead of ruling out phones or tablets categorically.

Choose the surface around the job and make the next action clear. Your customer should not have to fight a miniature desktop to finish it.

A bad mobile experience does not stay in the app. It damages trust in the whole brand, and in B2B the reaction is harsher than ever: a clumsy app invites the “I could build this over a weekend” crowd. Pick the jobs that belong on the phone and do those properly. Leave the rest where it works.

Qarma: capture on the floor, review at headquarters

In Qarma’s quality-inspection product, inspectors use the mobile app for checklists, defects and photos at the factory. Quality teams use the web product for planning, reports, approvals and corrective actions. The design connects the captured defect to the later decision rather than asking people to retype the same information.

That split gives a business a practical way to scope mobile app design: put capture and the next inspection step on the phone, while keeping the dense management work in the web platform. ANODA designed both product surfaces and their shared UI system; development was outside our scope.

The bill that arrives after launch

An app is a dog, not a sofa. You don’t buy it and put it in a corner; you feed it, walk it and take it to the vet, every year, whether you feel like it or not.

Plan compatibility checks when supported platforms change and budget for the release process of each distribution channel. New App Store versions are submitted for review; server-side content changes can follow a separate path. A new public place appears where customers can praise you or bury you, and someone has to answer those reviews. Permissions change how they are asked and granted. And your users already have settings switched on that your screens must survive: dark mode, larger text, higher contrast, reduced motion.

Google and Apple also ask for different things, sometimes contradictory ones, so “one app for both” still means two sets of rules to follow. If nobody on your side owns all of this, kicking the can down the road is not a plan. It is how an app quietly rots until the reviews say so in public.

Test the smallest app before you build the big one

You don’t need a full app to find out whether people want one. Take one recurring or device-specific task, design a complete path through it, and test it with the people who would use it. Observe completion and the relevant outcome; study return use when the task recurs. Add accounts or supporting features only where the core task needs them. Chat, loyalty points and dashboards can wait unless they are part of the job you are testing.

Use UX research to observe the task in its real setting before forecasting adoption. A focused MVP design should let you test a coherent task and its relevant outcome: repeat use for a recurring job, or successful capture and completion for a device-specific job. Throwing spaghetti at the wall is expensive when every strand is a native app release.

When the case is proven and it is time to build, our mobile app development team takes the design from there.

The decision on one page

An app is a product you operate, not a deliverable you receive. Build it when it makes an important recurring or device-specific task meaningfully easier, and the expected business benefit justifies its operating cost. Scope only the flows that belong on a phone, budget for every year after launch, and assume neither the install nor the notification. If the only argument left is that an app would look impressive, you know where the Ferrari dealership is.