Written by Tuan Nguyen · Published · Updated
Most weeks someone messages me asking for a new website. And most weeks, after two or three questions, it turns out they do not need a website at all. They need a small web app. The reverse happens too. Someone comes in sure they need a full custom platform with logins and dashboards, when a clean five page site would have done the job for a tenth of the price.
The two words get used like they mean the same thing. They do not. And the gap between them decides your budget, your timeline, and whether the thing you pay for actually removes the problem you have.
So before you spend anything, it is worth knowing which side of the line you are on.
The difference, in one line
A website mostly shows. Someone lands, reads, looks at your work, maybe fills in a contact form, and leaves knowing a bit more about you. Think of a storefront window. Most marketing sites and portfolios are exactly that, and there is nothing wrong with it. That is what they are for.
A web app mostly does. The visitor logs in, puts something in, gets something back, and something changes because of it. A slot gets booked. An invoice gets made. A job moves one step down a pipeline. It is less a window and more a small machine your customers or your team operate every day.
Here is the test I use. If people mostly read, you want a website. If people need to do something and get a result back, you want a web app. Most of the confusion clears up right there.
Five questions that settle it
You can answer these yourself in a few minutes.
Do people need to log in. If different users have their own account, their own saved data, their own private view, that is app territory. A brochure site almost never needs a login.
Does it need to remember and change data. Booking a time, tracking an order, updating a status, anything that stores what a user did and behaves differently next time, is an app.
Are you trying to kill a spreadsheet. This one is the loudest signal. When someone tells me right now my team does this in a spreadsheet and it is a mess, they almost always need a small app, not a prettier website.
Is the goal to win trust, or to run the work. Winning trust and collecting leads is a website job. Running a piece of the business day to day is an app job.
Does the screen change per person. If it looks the same to everyone, website. If it looks different for every user based on their own data, app.
Count your answers. If the login, data, and spreadsheet ones came back yes, you are looking at a web app. If it is mostly about showing your business well and getting people to reach out, a website is the smarter spend, and I will tell you that even though the app pays me more.
What getting it wrong actually costs
Build an app when you only needed a website, and you pay for logins, databases, and logic you will never touch. Often several times the money and the months, to solve something a simple site would have solved on its own.
Build a website when you needed an app, and the damage is quieter, which is what makes it worse. You launch, it looks great, everyone nods. Then Monday comes and you are still doing the real work by hand, in spreadsheets and email, exactly like before. The site changed nothing about the actual pain. It just cost money and bought a nicer brochure.
There is a middle that most people miss. A solid website with one working piece bolted on. A booking flow. A quote calculator. A client login area. Most small businesses do not need a full platform. They need a good site plus one thing that does real work. Start there. You can grow it later, when the need is real instead of imagined.
How I would work it out with you
When someone brings me a project, I do not open with website or app. I open with the job. What is this supposed to accomplish, and how will we both know it worked. More booked calls this month. Ten hours a week off your admin. Fewer of the same question landing in your inbox.
Once the job is clear, the format usually answers itself. And more often than people expect, the honest answer is less than you thought. I would rather build you a lean first version that does one thing well and put it live, than sell you a big system you do not need yet and cannot fully use.
If you are not sure which side your idea sits on, that is a good thing to figure out before anyone writes a line of code, and I am happy to help you name it. You can see how I approach these builds if you want a sense of how I work first.
So maybe the better question is not which one to build. It is this. What is the one job you want it to do first?
