Web app vs website vs mobile app: the difference

A website publishes information to anyone who shows up. A web app lets a logged-in person do work inside a browser. A mobile app is software installed on a phone from the App Store or Google Play. That is the whole distinction, and almost every confused conversation about budget starts with someone using one word while meaning another.

The reason it matters is money. Those three things cost roughly $1,800 to $25,000, $12,000 to $60,000, and $20,000 to $75,000 respectively. Picking the wrong word in a kickoff meeting can move a project by a factor of ten. Below are clean definitions, a side-by-side table, the fourth option most people have never had explained to them, and what each one looks like for three real kinds of Minnesota organization.

What is a website?

A website is a set of pages at a public address that shows essentially the same content to everyone who visits. Its job is to inform, persuade, and get someone to take one next step: call, donate, apply, book, or buy. Nobody logs in. Nothing is personalized beyond what the visitor typed into a search box.

Most of what you use is still this. A church listing its prayer times, a home care agency listing its services and counties, a law firm explaining what it handles. These sites can be sophisticated, with hundreds of pages, an events calendar, and forms that route to different inboxes, and they are still websites.

Cost runs $1,800 to $3,500 for a starter site, $3,500 to $9,000 for a typical business or nonprofit site, and $9,000 to $25,000 for something large or custom. The ranges are on our pricing page and they have not moved much in three years.

What is a web app?

A web app runs in the same browser at the same kind of address, but it has accounts, it remembers what you do, and it shows each person a different screen based on who they are. Gmail is a web app. Your payroll system is a web app. So is the page where a client checks their invoice history.

The technical line is not really about code. It is about state. If the software has to save what someone did and show it back to them or to somebody else later, you have crossed from website into application, and the cost structure changes completely. You are now paying for user roles, permissions, a database, an admin view, edge cases, and the two months of testing that all of that requires.

An internal tool that replaces one spreadsheet or one paper form runs $6,000 to $25,000. A full web application or customer portal runs $12,000 to $60,000. The difference between those two numbers is almost always the number of distinct people who log in and how differently they need to be treated.

What is a mobile app?

A mobile app is a program installed on a phone, distributed through Apple’s App Store or Google Play, that can use hardware the browser cannot fully reach and can work with no signal at all. It gets a home screen icon, it can send push notifications reliably, and it gets reviewed by Apple and Google before anyone can download it.

The install requirement is the part people underestimate. Every mobile app asks a person to find it, download it, create an account, and then remember it exists. That is a real barrier, and it is why so many organizational apps sit at a few hundred installs and get quietly retired.

Building for both iOS and Android runs $20,000 to $75,000, plus $99 per year for Apple’s Developer Program and a one-time $25 registration fee for Google Play. If you are weighing this seriously, read our breakdown of what it costs to build an app and the comparison of native vs cross-platform before you talk to anyone about a quote.

How do a website, web app, and mobile app compare?

Factor	Website	Web app	Mobile app
What it is	Pages that inform and convert	Software with accounts and saved data	Software installed on a phone
Where it runs	Any browser	Any browser	iOS and Android devices
Install required	No	No	Yes, from an app store
Typical cost	$1,800 – $25,000	$12,000 – $60,000	$20,000 – $75,000
Typical timeline	2 – 16 weeks	8 – 24 weeks	12 – 28 weeks
Best for	Being found, explaining, first contact	Repeat work by a known group of users	Daily use, offline, camera, GPS, push
Worst for	Anything requiring a login and saved records	One-time visitors who just want your phone number	Anything used a few times a year
How users find it	Google, Maps, referrals, your printed materials	A link and a login you give them	App store search, or you tell them to install it
How updates work	Publish, live immediately	Deploy, live immediately for everyone	Submit for store review, then users choose to update

The last row causes more long-term pain than any other. On the web, a bug you find on Tuesday is fixed for everyone on Tuesday. With a mobile app, a fix goes through store review and then only reaches people who actually update, so you support old versions for months whether you planned to or not.

What about a progressive web app?

A progressive web app, or PWA, is the fourth option and the one that gets skipped in most sales conversations. It is a web app built so a phone can install it to the home screen, run it full screen without browser bars, cache enough to work offline, and send push notifications. No app store, no review queue, no yearly developer fee.

On Android this has worked well for years. On iOS it works too, including push notifications, but only once the user adds the app to their home screen from Safari, which is a step you have to actually teach people. That instruction step is the honest cost of a PWA.

Cost tracks the application logic behind it, and it lands well below a native build for the same feature set because it is one codebase serving desktop and phone. For a delivery driver checklist, a volunteer sign-in, a caregiver shift view, or a member directory, a PWA usually does the whole job.

Choose native over a PWA when App Store presence is itself the goal, when you need deep hardware access such as Bluetooth peripherals or background location, or when your users genuinely expect to find you by searching the store. Otherwise start with the web version. You can always wrap or rebuild later with real usage data instead of guesses.

What does the word portal actually mean?

Portal means a logged-in area. That is all. It is the vaguest word in this business and it appears in maybe half the app inquiries we get, usually with no definition attached, and then people are shocked when two quotes come back $40,000 apart.

The quotes differ because the word covers everything from a page that shows a PDF to an authenticated user, to a system with five roles, document uploads, an audit trail, and a nightly sync with a state database. Same word. Different decade of work.

Before you request a quote for a portal, write down four things. Who logs in, listed by role. What each role sees when they land. What each role can change. What existing system it has to talk to. If you can answer those, any competent shop can price it within a week. If you cannot, you are asking vendors to guess, and the ones who guess low win the job and then bill you for the difference in change orders.

Our glossary has plain-English definitions for the other words that show up in these quotes, including API, CMS, and single sign-on.

What does this look like for a real organization?

Three shapes, drawn from the kinds of clients we work with most across the Twin Cities.

A charter school. The website does admissions. Enrollment dates, the lottery process, staff directory, calendar, lunch menus, bus routes, and news, all in the languages families actually read. That is a website, and for most schools it is the only thing worth building. We built the site for Gateway STEM Academy, a public K-8 charter in St. Paul, on exactly that logic. A parent portal only becomes a separate web app when families need to log in and do something the school’s student information system does not already handle. Most schools already pay for a system that does grades, attendance, and messaging, and building a second one is a waste. More on the trade-offs in our guide to school website design.

A home care agency. The website does two jobs at once, and they pull in opposite directions: it recruits caregivers and it reassures families. Those are different visitors who need different paths from the homepage. That is still a website, and it is where the first $5,000 to $9,000 should go. A caregiver scheduling and shift-note web app is a separate project at $12,000 and up, and it is worth building only if your agency management software genuinely cannot do it. You can see that split on the site we built for CityLight Home Care in Edina, and the reasoning behind it in our guide to home care website design.

A retail brand. An online store is a website with commerce attached, priced $3,500 to $20,000 depending on catalog size and how much custom work the checkout needs. It is not a web app in the sense above, because Shopify or WooCommerce already supplies the accounts and order history. Zolasina, a sustainable clothing brand we built for, sells this way. A store this size does not need a mobile app, and building one would mean paying to acquire installs from customers who were already going to buy from the site.

When should you not spend money on any of this?

Plenty of times, and I would rather say so now than three meetings in.

If you already pay for software that does the thing, do not have us rebuild it. Care providers running an agency management platform, schools on a student information system, clinics on an EHR, gyms on a membership platform: those tools include portals, scheduling, and messaging. A custom version will be worse than the one you have and will cost $20,000 to find that out. Push your vendor to turn the feature on first.

If under about twenty people would use the tool and the process fits a spreadsheet, use the spreadsheet, or an inexpensive off-the-shelf tool like Airtable, Jotform, or a shared calendar. Custom software earns its cost through volume or through a workflow nothing off-the-shelf matches. Fifteen users and a simple checklist is neither.

And if your website is slow, thin, or invisible in search, fix that before funding an application. An app nobody can find is an expensive way to serve the customers you already had. Our post on why websites get traffic but no leads covers where that money usually goes furthest.

How do you decide which one you need?

Answer these in order, and stop at the first yes.

Do people mainly need to find you, understand you, and contact you? Build a website. Do a known group of people need to log in and do repeated work? Build a web app, and write down the roles first. Do those people need it on a phone, in a car, in a basement with no signal, several times a week? Build a PWA and see whether that is enough. Do you still need the camera, background location, Bluetooth, or store discovery after six months of real usage? Now build the native app, and you will build a better one for having waited.

The order matters because every step up multiplies both the build cost and the yearly maintenance. Expect to budget a meaningful share of the original build cost every year to keep an application healthy, versus $75 to $600 per month for a website care plan.

If you want a straight opinion on which of the four your project actually is, tell us what you are trying to do and we will tell you, including when the answer is that you should not build anything. We are at 4951 W 77th St in Edina and reachable at (612) 293-0636.