The difference in one sentence
A website tells people about your business. A web application does a job for them.
A website answers questions: who you are, what you do, how to reach you. It does the same thing for every visitor. A web application takes something from the visitor, does work with it and hands something back. It behaves differently for each person using it.
Most owners who write to us are not sure which one they are asking for. The price difference is large enough that it is worth settling before anyone starts building.
Four tests
Run your idea through these in order. The more of them you answer yes to, the further you are into web application territory.
Does anyone log in?
An account is the clearest line there is. The moment a visitor has a password, your site has to remember who they are, keep their information away from everyone else and let them back in when they forget it. None of that exists on a website, and all of it has to exist on an app.
Does it remember anything?
A website forgets you the second you leave. An app keeps a record. A saved search, a draft, a list of what you looked at last time, a map you built on Tuesday and want back on Friday. If your idea depends on the thing remembering, you need a database behind it and a plan for keeping that data safe.
Does money move?
Taking a payment is a job, and it comes with rules. Card details, receipts, refunds, subscriptions that renew, subscriptions that lapse. A single “pay now” button can be bolted onto a website through a checkout service. Recurring billing tied to an account is an app, every time.
Does the visitor take something away?
Websites are read. Apps produce. A quote, a report, a booking confirmation, an embeddable map, a PDF built from what the visitor typed in. If the visitor leaves with something that did not exist before they arrived, the thing that made it is an application.
The middle ground, where most businesses land
Most small businesses need a website with one working part. A mortgage calculator on a lender’s site. A booking form that checks a calendar. A map that shows where the trucks go. An interactive chart that redraws when the visitor picks a different year.
That is still a website. The working part does not need an account, does not remember the visitor and does not move money. It runs in the browser, does its small job and goes quiet. It should be built with care, but it does not drag the whole project across the line.
Our own work has a clean example. henrymeigs.com is a real estate website with nine neighborhood market pages. Each page carries interactive demand charts that a visitor can explore. Those charts are real code, and they are the most technical thing on the site. The site is still a website. Nobody logs in, nothing is stored about the visitor, and every person sees the same pages. The charts make it better without making it an app.
The test for the middle ground is simple. Take the interactive piece away. If what remains is still the product, you have a website with a feature. If what remains is a brochure for the thing you just removed, the feature was the product, and you are building an app.
What changes when you cross the line
Crossing from website to web application changes five things, and each one costs something for as long as the app is alive.
- Hosting. A website can sit on a single small server and serve every visitor the same files. An app runs code for each request, so it needs a server that can scale up when it is busy and a way to deploy changes without downtime.
- A database. Anything the app remembers has to live somewhere, with backups, and with a plan for what happens when a table needs a new column two years from now.
- Security. A website has nothing to steal. An app holds accounts, and sometimes payment records, so it needs password handling, access rules, rate limits and someone watching the logs.
- Testing. A website either loads or it does not. An app can fail in a hundred quiet ways: a form that saves the wrong thing, a subscription that renews twice, a map that works for one user and breaks for the next. Every path gets tested, and gets tested again after each change.
- Ongoing cost. A website mostly costs money to build. An app costs money to run. The server, the database, the payment processor and the person keeping it all current are monthly line items, not a one-time invoice.
Know which one you are building before you agree to a price.
Pathway, as a worked example
Pathway is a web application we built, and it fails all four tests in the right direction. It turns any address into a curated neighborhood map that drops into a listing page with one line of code.
Agents log in. The app remembers every map they build and every pin they place. Stripe handles subscriptions, so money moves every month. And the visitor takes something away: a working, embeddable map that did not exist before they typed in an address. Behind it sit Flask, MapLibre GL, PostgreSQL and Stripe, with accounts, billing and per-pin analytics.
Strip the map builder out of Pathway and nothing is left. The feature is the product, which is why it was built as an app from the first day instead of as a website that grew a login later.
The honest answer for most owners
If you are a restaurant, a contractor, a law office, a realtor or a shop with one product, you almost certainly need a website. You may need one working part on it, and that part deserves to be built well. You do not need accounts, a database or a monthly hosting bill that scales.
If your business idea is the tool itself, you need an app, and you should plan for it as a product with running costs and a roadmap.
Letter Box Digital builds bespoke websites and web applications in Philadelphia, and we take both kinds of project. What we will not do is sell you the second when you need the first. If you are unsure, the four tests above will get you most of the way, and our web application page covers what the build looks like when the answer is yes.
Questions owners ask
Can a website turn into an app later?
Yes, if it was built with that in mind. Our sites are built from scratch on Flask and PostgreSQL, which is the same foundation our apps use, so adding accounts or a database later is an extension of the existing build. A site assembled from a theme and plugins usually has to be rebuilt to get there.
Is an app always more expensive?
To build and to run, yes. There is more to test, and the thing is doing work every day. The right comparison is app versus the cost of doing that job by hand, forever.
How do I describe what I want if I do not know the words?
Describe the job, not the technology. Who uses it, what they do, what they leave with. That is the same way we start every project, and how we work puts a working prototype in your hands before anything is final, so you will know which one you are getting long before it is finished.