Strategy
Website, web app or mobile app: which one do you actually need?
Three different builds, three different costs, and a lot of founders paying for the wrong one. A plain-English way to tell them apart before you brief anyone.
"We need an app." We hear it weekly, and about half the time the thing being described is a website with a login, which is a different job, a different budget and a different timeline.
The words get used loosely, so here is the version we use with clients before anyone writes a brief.
A website is pages people read
Your marketing site. Homepage, service and product pages, industry pages, blog, case studies, careers. The content is the product, and your team should be able to change the words without opening code.
You need one if: buyers find you through search, referral or outreach and need to work out what you do and whether you are safe to talk to.
The test: if nobody has to log in, and nothing needs to be remembered between visits, it is a website.
Typical build: two to six weeks, depending on page count. The main cost driver is the number of distinct page types, not the number of pages.
A web app is software people log into
Dashboards, customer portals, admin panels, internal tools, the first version of a product. It runs in a browser, it knows who you are, it stores things and it applies rules.
You need one if: different people should see different things, or the thing has to remember state between sessions, or someone is currently doing the job in a spreadsheet that has become load-bearing.
The test: does it need a login and a database? Then it is a web app, whatever it looks like.
Typical build: four to twelve weeks for a first working version. The cost driver is the data model and the number of roles, not the number of screens. Two roles and one clean data model is a small project. Five roles, approvals and an audit trail is not.
A mobile app is the icon on a home screen
Installed from the App Store or Play Store, sitting on the phone, with access to things a browser cannot reach comfortably: camera, GPS in the background, offline storage, push notifications.
You need one if: your users are on their feet, offline, or in a job where opening a browser and typing a URL is friction that kills adoption. Field teams, drivers, technicians, warehouse staff, anyone wearing gloves.
The test: does it need to work with no signal, or send notifications, or use the camera or location while the app is in someone's pocket? If not, a good mobile website does the job and costs a fraction.
Typical build: six to fourteen weeks for a first release, plus store review. One codebase can cover iOS and Android, so you are not paying twice, but you are still paying for two stores, two review processes and two sets of release chores.
The honest comparison
| Website | Web app | Mobile app | |
|---|---|---|---|
| Who it is for | Buyers evaluating you | Customers or staff using you | People on the move |
| Login | No | Yes | Usually |
| Who edits the content | Marketing, via a CMS | Nobody, it is data | Nobody, it is data |
| Where it lives | A URL | A URL | A store listing |
| Time to first version | 2 to 6 weeks | 4 to 12 weeks | 6 to 14 weeks |
| What kills the budget | Page count creep | Roles and edge cases | Store rules and devices |
Three common mis-briefs
"We need an app so people can check their orders." That is a web app, and quite possibly a page behind a login on the site you already have. Build it there, see whether anyone uses it, then consider a phone app.
"We need a website, but customers should be able to log in and download reports." That is a website plus a small web app, and the two should be scoped separately so the marketing site is not held hostage by the login work.
"We need a mobile app for our sales team." Sometimes true. More often what is needed is a mobile-first web app and a bookmark, because getting a sales team to install and update an internal app is its own project.
The question that settles it
Forget the format and finish this sentence: "A person should be able to ______, from ______, without ______."
- "A buyer should be able to understand what we do, from a Google result, without talking to us." Website.
- "A customer should be able to see their invoices, from their laptop, without emailing support." Web app.
- "A technician should be able to log a job, from a basement with no signal, without a laptop." Mobile app.
Nine times out of ten the sentence names the build, and it takes ten seconds.
Where front end and back end come in
One more piece of vocabulary, because it decides who you need to hire.
Front end is what people see: the screens, the layout, the words, the animation, the way it responds to a tap. Back end is what remembers: the database, the logins, the business rules, the payments, the connections to your CRM and ERP.
A website is mostly front end with a CMS behind it. A web app and a mobile app are both, in roughly equal measure, and the back end usually outlives the front end by years. If a quote only covers screens, ask who is building the half nobody sees.
What to do before you brief anyone
Write down, on one page: what a person should be able to do, who logs in, what data it touches, which systems it has to talk to by name, and who will maintain it after launch. That page is worth more than a feature list, and it will save you from buying the wrong build twice.
