Web app or website: which are you actually asking for?

Two business owners call us in the same week. Both say the same sentence: "We need a website." One of them needs a website. The other needs customers to log in, book time slots, pay deposits, and get automated reminders. Those are two different products, they're built with different tools, and one costs about ten times the other. Sorting out which one you're actually asking for is the most valuable five minutes of any software conversation.

The distinction in one line

A website shows information. A web app does work.

A website is your services, your photos, your hours, your phone number, maybe a blog. Visitors read it and then call or email you. The pages are the same for everyone who visits. Think of it as a brochure that's always up to date and findable on Google.

A web app has users, not just visitors. People log in and see things that belong to them. They create, change, and submit data, and the system responds: a booking gets confirmed, an invoice gets generated, a status changes. Think online banking, a scheduling system, a customer portal. It's software that happens to live in a browser.

Why the price gap is 10x, not 20%

From the outside, both are "a website," so the price gap looks like markup. It isn't. The gap comes from what has to exist behind the screen.

• A website has no moving parts. Pages get written once and served to everyone. There's no database, no login, no user data. Hosting costs a few dollars a month or nothing, and there's almost nothing that can break. A solid small-business site is days to a few weeks of work.
• A web app is a running system. It needs a database, user accounts, password resets, permission rules (customers must never see each other's data), input validation, a server that's always on, backups, and security review. Every screen where a user can do something is logic somebody has to design, build, and test, including all the ways it can go wrong. That's why even a modest app is measured in months.
• The ongoing costs differ the same way. A website can sit untouched for three years and be fine. An app has server bills, security patches, and a real answer required for "what happens if this goes down on a Saturday." When you buy an app, you're adopting a system, not receiving a file.

Ballpark it this way: if a static site is a few thousand dollars, the app version of the same business's needs usually starts in the tens of thousands. Not because anyone is padding. Because there's ten times as much to build and it has to keep running.

The quick self-diagnosis

Go through what you want the thing to do and sort each item into two buckets:

• Website bucket: describe our services, show our work, publish articles, display hours and location, let people contact us, look credible.
• App bucket: let customers log in, take bookings or orders, accept payments tied to accounts, show each customer their own status or documents, let staff update records, send automated notifications.

If everything lands in the first bucket, you need a website, and you should be suspicious of any quote with a comma in it. If anything lands in the second bucket, that item is the actual project, and the informational pages are the cheap part bolted on front.

One clarification, because it trips people up: a contact form doesn't make your site an app. Neither does a map, a photo gallery, or a link out to a third-party booking tool. The line is whether your system stores and works with user data itself.

The middle path most businesses should take

Here's the part that saves real money. A lot of "app bucket" items can be handled by existing services stitched into a plain website. Online booking: Calendly or Square Appointments, embedded on your site. Payments: a Stripe payment link. Newsletters, reviews, simple e-commerce: all solved by services that cost tens of dollars a month instead of tens of thousands up front.

We steer clients this way constantly. Start with a good static site plus off-the-shelf services. Build custom software only when an off-the-shelf tool genuinely can't do the job, or when the workflow you need is the thing that makes your business different. Custom is for competitive advantage, not for rebuilding what Calendly already does.

How to know you're being quoted honestly

When you talk to a builder, watch for one thing: do they ask what the site needs to do before naming a number? Anyone who quotes without separating the brochure from the machinery is guessing, and their guess will be wrong in whichever direction hurts you.

A good conversation sounds like this: "These five pages are a website, that's the small number. The customer login you described is an app, that's the big number, and here's a service that might cover it for $30 a month instead. Which parts are worth building?" If you hear that, you're in good hands. It's the conversation we have with every client before a dollar is scoped, because the cheapest software mistake is the one you catch before anything gets built.