Website or app? How to decide

Build a website unless you have repeat users with a reason to install. That is the whole decision, and everything below is a way of testing whether you actually have those users or just hope you do.

The question people bring us is usually phrased as which one is better. That framing has no answer. A website and an app are not competing versions of the same thing. A website is how strangers find you and decide whether to trust you. An app is a tool you hand to people who already know you and are coming back on purpose. Confusing the two is how organizations spend $40,000 to reach an audience that was never going to install anything.

The five tests

Answer these honestly. Not how you want your organization to work in three years, but how people behave today.

1. Do the same people come back weekly or more? Weekly is the real threshold. A parent checking a therapy schedule, a driver picking up dispatches, a member logging a workout. Those are weekly behaviors. Finding your phone number, reading your program page, or donating once a year is not. If your honest answer is monthly or seasonal, the app will sit on a home screen unopened until it gets deleted.

2. Do you need something the browser genuinely cannot do? Camera, GPS in the background, offline access with no signal, hardware sensors, biometric login, reliable push on iPhone. Modern browsers do more of this than most people assume, and the gaps have narrowed a lot. Be specific about which capability you need and why. “It would feel more professional” is not a capability.

3. Is the interaction long enough to justify installing? Installing is a real cost to the user. Finding the app, remembering their password, granting permissions, waiting for a download. If the thing they came to do takes eleven seconds, they will not pay that toll. Apps win where the session is substantial or repeated so often that the install amortizes.

4. Do you have a plan to get it installed? This is the test that kills the most projects, and it comes up last in almost every conversation. Downloads do not happen because the app exists. Someone has to tell each person to install it, repeatedly. If you cannot name the specific moment when you will ask, and who will ask, you do not have a distribution plan.

5. Can you fund it every year, forever? Apps decay faster than websites. Apple and Google ship OS updates annually, deprecate APIs, and change store requirements. Budget 15% to 25% of the build cost each year or plan on a rebuild in three.

Tests you pass	What to build
0 – 2	A fast mobile website. Nothing else.
3	A website first, revisit the app after you can point at real usage data.
4	A progressive web app, or a web app behind a login.
5	A native or cross-platform app is defensible. Scope it tightly.

Notice what is not on this list: your competitors have one, your board asked about one, or it would make you look modern. Those are real pressures and they are not reasons.

How do a website, a PWA, and a native app compare?

Here is the comparison that matters, using the ranges we publish on our pricing page.

	Mobile website	Progressive web app	Native / cross-platform app
Typical cost	$1,800 – $9,000	$3,500 – $9,000	$20,000 – $75,000
Time to launch	2 – 8 weeks	4 – 8 weeks	Months, not weeks
How people find it	Google, maps, referrals, ads	Same as a website	Only if you send them to the store
Shipping a change	Minutes. You publish it.	Minutes. You publish it.	Days. App review, then users must update.
Yearly upkeep	$75 – $600/mo care plan	$75 – $600/mo care plan	15% – 25% of build cost, plus store fees
Store fees	None	None	$99/yr Apple, $25 one-time Google
Push notifications	No	Android yes, iPhone only after Home Screen install	Yes, both platforms
Works offline	No	Yes, for visited content	Yes
Rejection risk	None	None	Real. Apple reviews every release.

The row people underweight is “shipping a change.” On a website, fixing a wrong phone number takes two minutes. On an app, you fix it, rebuild, submit, wait for review, then wait for users who have automatic updates turned off. Every small correction becomes a small project. Over a year that friction shapes how your organization operates more than any feature does.

Does anyone actually find your app by browsing the store?

No. This is the single most common misunderstanding, and it is worth being blunt about.

App store search is overwhelmingly people typing the name of something they already heard about somewhere else. Nobody opens the App Store, browses a category, and discovers a Twin Cities home care agency. The store is a delivery mechanism, not a discovery channel. It is closer to a warehouse than a storefront.

Which means an app does not replace your marketing. You still need the website, the Google Business Profile, the local search work, and the word of mouth. All the app does is add a second thing to promote, using the first thing to promote it. If your website is not already bringing you the people you want, an app will not fix that, and you should read why your website gets traffic but no leads before you spend anything on a store listing.

What can a website do now that used to require an app?

More than most people realize, which changes the math.

A progressive web app gets a Home Screen icon and opens full screen with no browser bar. Most users cannot tell it is not an app. It caches pages so it keeps working in a parking ramp with no signal. It can use the camera for a photo upload or a scan, and it can use location with permission. On Android it sends push notifications.

The iPhone caveat is the honest limit. iPhones do support web push, but only after someone adds your site to their Home Screen from Safari. That extra step is a real drop-off, so if push to iPhone users is central to how your thing works, that is a genuine point for native. If push is a nice-to-have you would send twice a month, it is not.

The other quiet advantage is that a PWA is still a website. It shows up in Google. You can link to any screen. There is no review queue. You are not asking anyone to install anything before they can see whether it is useful.

What still genuinely requires a native app?

Some things do, and pretending otherwise would be dishonest.

Background location tracking, which means a driver app that logs a route while the phone is in a pocket. Continuous Bluetooth or hardware connections. Heavy offline data that has to sync when signal returns. Anything needing reliable push to iPhone users who will not add a Home Screen icon. Deep integration with the phone, like a share sheet extension or a widget. Consumer products where being in the store is part of how people evaluate whether you are real.

If two or three of those describe your project, look at native versus cross-platform next, because that decision changes your budget by tens of thousands of dollars.

What does the right call look like in practice?

The clearest way to see the framework is against real organizations.

A therapy clinic like NuuroTherapy in Burnsville has parents who genuinely interact weekly. That passes test one. But the thing parents need most is to find the clinic, understand ABA and speech services, and get through intake, which is a first-visit job and pure website work. The weekly interaction, scheduling and progress notes, usually already lives in a practice management system that has its own portal. Building a second app to duplicate it would cost $30,000 and confuse people.

A home care agency like CityLight Home Care fails almost every test on the family side. Families research once, in a stressful week, on a phone, and call. What they need is a fast page that explains services and 245D waiver questions clearly, not something to install. The place an app case could exist for a home care agency is on the caregiver side, scheduling, visit verification, and clock-in. That is a real workforce tool, and it is usually cheaper to buy existing EVV software than to commission one.

A masjid is the most interesting case, because it is the one that most often passes. Daily prayer times, iqamah changes, Ramadan schedules, and janazah announcements are genuine weekly-or-more, time-sensitive, push-shaped needs. Even so, our advice to congregations like Masjid As-Sunnah is usually to start with a strong mosque website that publishes prayer times cleanly and works on a five-year-old Android phone, then add a PWA layer if community members are actually asking for notifications. Many congregations discover the existing prayer time apps people already have installed cover it.

The wrong call has a recognizable shape. An organization commissions an app, launches it, gets a few hundred downloads from people who were already on the email list, watches usage fall off over two months, and then quietly stops paying for maintenance. Eighteen months later the app will not open on the current version of iOS. Nobody complains, because nobody was using it. That money bought nothing, and the same budget spent on the website and local search would still be working.

Should you hire us for this?

Sometimes the honest answer is no, so here it is.

If you have a decent mobile website that loads fast and your traffic is not converting, do not buy an app and do not buy a redesign. Fix the pages you have. That is often a few hundred dollars of work, or free if you do it yourself. Our article on why your website is slow covers most of what would move the needle.

If you genuinely need a complex consumer app with a multi-year roadmap, a dedicated product team, and continuous release cycles, we are not the best fit and we will tell you that in the first call. A shop with full-time iOS and Android engineers and a product manager will serve you better than a studio that does most of its work on the web. Hiring the wrong kind of firm is more expensive than hiring the more expensive firm.

And if you are a nonprofit weighing an app against a year of program spending, the app almost never wins. We would rather you put $30,000 into the work and $6,000 into a website that funds it.

Most organizations that come to us asking for an app leave with a plan to build web first. Not because we cannot build apps. We build mobile apps and web applications, and when the five tests come back positive we say so. It is because the app was usually standing in for a problem, reaching people, looking credible, making something easier, that web solves for a tenth of the price and a quarter of the time.

What should you do next?

Run the five tests with somebody who will disagree with you. If you pass three or fewer, put the budget into a mobile-first website and the local search work that feeds it, and revisit in a year with real numbers. If you pass four or five, get specific about scope before anyone quotes you, because the cost of building an app tracks scope far more than technology. If you are still unsure which category your project falls into, the difference between a web app, a website, and a mobile app is worth twenty minutes of reading.

If you want a second opinion on which side of the line your project sits, get in touch or call (612) 293-0636. We will tell you if the answer is a website, which it usually is, and we do not charge for that conversation.