The Short Answer
Almost every small business asking this question needs the website. A meaningful minority needs a logged-in area behind it. Very few need a native app in the App Store, and the reason is not cost.
It is distribution. A website is found by people who do not yet know you exist. An app has to be installed by someone who already does. If your problem is being found, an app cannot solve it — it puts an install step in front of the thing you wanted the stranger to do.
There is a second problem with the question, which is that three different things get called "an app," and they have almost nothing in common.
Three Things Called "An App"
| Mobile-friendly website | Web app (logged in) | Native app | |
|---|---|---|---|
| What it is | Your public site, built to work on a phone | A private area behind a login: bookings, documents, job history, payments | A program distributed through the App Store and Google Play |
| How someone reaches it | A link, a search result, a text message | A link plus a login | Find it in a store, install it, open it |
| Found by strangers? | Yes — this is the only one that is | No, and deliberately so | Only by store search, which strangers rarely use to find a local business |
| Gatekeepers | None | None | Apple App Review and Google Play policy |
| What breaks if unmaintained | Nothing immediately; it keeps rendering | Dependencies age, same as any software | It eventually stops installing on current phones |
Most businesses that genuinely need more than the first one need the second. The third is a different kind of project with a different kind of risk, and it is worth being specific about why.
The Discovery Problem Decides Most of This
A website and an app sit at opposite ends of the customer relationship.
The website is an acquisition surface. Its entire job is to be found by someone who typed a problem into Google and has never heard your name. Everything about how we build — the technical SEO foundation, the structured data, the speed work — exists to serve that one job.
An app is a retention surface. Its job is to make a relationship you already have more convenient and more frequent. That makes it a good investment for a business whose customers interact weekly and a poor one for a business whose customers interact once every few years.
Here is the version of this we can prove from our own work rather than assert. On every project where we build an authenticated web application, we ship a robots.txt that disallows the whole thing and we do not generate a sitemap or an llms.txt for it. There is nothing behind a login that we want indexed, and pretending otherwise would just leak private URLs into search results. The logged-in surface is deliberately invisible to search engines.
That is the whole argument in one technical detail. The surface strangers find and the surface customers log into are two different things with opposite requirements. A business that needs both needs both. Neither one replaces the other.
What the App Stores Actually Require
This is the part that does not come up in the sales call, and it is where "we'll just turn your website into an app" offers tend to die.
Apple is the harder gate. Review guideline 4.2, Minimum Functionality, reads:
"Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store."
Guideline 4.2.2 adds that "other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." A brochure site in a shell is specifically what that describes.
And guideline 4.2.6 is the one that quietly rules out most low-cost app offers sold to small businesses:
"Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. These services should not submit apps on behalf of their clients."
So if someone is selling you a monthly app subscription built from their template and submitted under their developer account, that arrangement is against the rule you are being asked to rely on. The guideline does allow template providers to run a single aggregated or "picker" app hosting many clients — which is a real option, and also means your business is a page inside somebody else's app rather than an app of your own.
Google Play is more permissive, and the distinction matters. Play's spam policy says it does not allow apps whose primary purpose is to "provide a webview of a website without permission from the website owner or administrator." You are the website owner, so wrapping your own site is not automatically disqualified there. But Play has a separate rule: "we do not allow apps that only have limited functionality and content," with "apps that are static without app-specific functionalities, for example, text only or PDF file apps" named as a common violation.
Net result for a small business: a wrapper of your own website can plausibly ship on Android and will have a hard time on iOS. That is half a distribution strategy, with the full maintenance bill.
The Costs Nobody Puts in the Quote
The store fees are the trivial part, and they are worth stating precisely anyway because they are so often inflated in sales conversations.
- Apple Developer Program: "the Apple Developer Program annual fee is 99 USD," per Apple's own enrollment documentation, and you need to enroll "if you'd like to distribute apps."
- Google Play: a "US$25 one-time registration fee," non-refundable if your identity information is determined to be invalid.
- Commission on anything sold in-app: Apple's Small Business Program offers "a reduced commission rate of 15% on paid apps and Apple In-App Purchases" to developers who made "up to 1 million USD in proceeds in the prior calendar year," with the standard rate applying to future sales once that threshold is passed.
A hundred and twenty-four dollars is not the problem. The problem is everything downstream of it: two platforms to test on, a review queue between you and every change you want to ship, and an operating-system release cycle that does not care whether anyone is still maintaining your app.
That last one is the asymmetry worth internalizing. A website nobody has touched in two years still loads. An app nobody has touched in two years eventually stops being installable, and the fix is a development project rather than an edit. Keeping either one current is ongoing work — it is the same reason scheduled updates and recurring content are a line item on a website rather than a one-time task — but the consequence of neglect is far steeper on the app side.
The Push Notification Argument Expired
For years the strongest honest reason to build native was push notifications. That changed.
Since iOS and iPadOS 16.4, a web app the user has added to the Home Screen can request permission to receive push notifications. Per Apple's own announcement, those notifications "show on the Lock Screen, in Notification Center, and on a paired Apple Watch," the Badging API is supported so the icon can carry a count, and — the part that matters most here — "you do not need to be a member of the Apple Developer Program to use it." Android has supported web push for considerably longer.
Two honest caveats, because this is not a free lunch:
The user has to add the site to their Home Screen first, and that is a real friction step. It is a smaller ask than an App Store install, and you can ask for it at a moment when the customer already wants something from you, but it is not zero. The practical test: if your customers will not add an icon, they were never going to complete a store install either.
And a Home Screen web app does not appear in App Store search. If your reason for wanting an app is that you want to be in the App Store, a progressive web app does not deliver that, and no amount of capability parity changes it.
When a Native App Is Actually Right
Four conditions. If you meet one, the conversation is worth having.
- You need a hardware capability the browser cannot reach for your specific use — certain Bluetooth peripherals, NFC writing, continuous background location, some camera and sensor work.
- Customers interact with you several times a week and want an icon. Gyms, salons with standing appointments, membership businesses, anything with a schedule people check habitually.
- The app is the product. You are selling software, not using software to sell something else.
- A franchise, platform or partner requires one. This happens, and it is a requirement rather than a decision.
If none of those is true, an app is a line item rather than a channel. The honest version of that conversation is worth having before the quote, not after.
What to Build, In Order
First, the mobile-friendly website. Not negotiable, because it is the only one of the three that strangers can find. If this is weak, nothing built on top of it compensates.
Then, if you have a repeat-customer workflow, the logged-in area behind it. This is what most businesses actually mean when they say they want an app: customers checking job status, booking a slot, paying a bill, pulling up a document, seeing their own history. Those are client portal, booking system and custom business software projects, and they run in a browser on a phone perfectly well. If the workflow is about tracking customers and follow-ups rather than serving them, it is a custom CRM instead — and whether to build that at all is the subject of build vs. buy software.
Then, and only with one of the four conditions above, the native app. By which point you will have a working web app to base it on, which is a much better starting position than a blank project.
What We Build and What We Don't
We should be plain about our own position here, because we are not neutral.
We build websites and web applications, including ones that work well on a phone and can be added to a home screen. We do not ship to the app stores — it is listed on our website development page under the heading for when we are the wrong choice, and it has been there since before this page existed.
That does shape what we can sell you. It does not change the recommendation, because the first two steps are the first two steps either way: get the public site right, then build the logged-in layer if the workflow justifies it. If you work through those and still meet one of the four native conditions, you will need a native developer, and you will be giving them a far cheaper brief than you would have today.
Our side of it is a $1,500 build with monthly plans from $20, and what moves the number on the web application half is broken down in how much custom software costs. If you are weighing this and want the version where someone argues the other side honestly, that is what a free consultation is for.
If You Only Do One Thing Today
Open your own website on your phone, as a customer, and complete the one action you most want a customer to take. Book the appointment, request the quote, find the price, make the call.
Count the taps and time it.
If that takes more than a handful of taps, or if you had to pinch to read something, you have a website problem — and an app would not have fixed it. It would have put a store listing, a download and an install in front of the same problem.