In the same year, we built two sites that could not be more different under the hood.
One is a website for an electrical contractor: static, built with Astro, no server, opens in under a second. The other is a booking platform for a pilates studio: a real application built with Next.js, with accounts, a database, and live class availability.
Both clients asked for "a website." Only one of them needed an application. Telling those two apart, before you build, is most of the job - and getting it wrong is expensive in both directions.
The question that actually decides it
Forget frameworks, budgets, and what looks impressive in a pitch. One question settles it:
Does a visitor need to do something that stores or changes data - or do they just need to read what you have published?
If every visitor sees the same pages, and the site's job is to inform (who you are, what you do, what it costs, how to reach you), that is a static site. If a visitor logs in, books a slot, places an order, or sees data that belongs to them, that is an application. Everything else - which framework, which host, how much it costs to run - follows from that one answer.
When a static site is the right answer
The electrical contractor's site needed to do one thing well: earn trust and get found. Show the work, the service areas, the credentials, the prices, and a clear way to make contact. None of that changes per visitor. It is the same page for everyone, every time.
So we built it static. A static site is a set of pages built in advance and served as-is. There is no application running on a server deciding what to show - the pages already exist, so they arrive almost instantly, even on a phone on a weak connection.
What you get:
- Speed. Nothing to compute on each request, so it is about as fast as the web gets.
- Almost no maintenance. No database to back up, no server software to patch, no application to keep alive. Less to break, and a far smaller attack surface.
- Cheap to host. Static files are inexpensive to serve.
And it is less limited than "static" sounds. A contact form, a booking enquiry, a newsletter signup - those can run through one small, single-purpose endpoint without turning the whole site into an application. You add the one dynamic piece you need, not a platform you do not.
What it cannot do is remember a specific visitor between pages. No accounts, no "your bookings," no per-person data. The moment you need that, you have changed categories.
When you actually need an app
The pilates studio needed something the electrical contractor's site never would: a person creates an account, logs in, sees the schedule, and books a spot - and that spot is then gone for everyone else.
That last part is the tell. What one visitor does changes what the next visitor sees. A booked slot has to disappear from the schedule in real time. That needs somewhere to store bookings (a database), a way to know who is logged in (accounts and sessions), and logic that stops two people grabbing the last spot at once. None of that can be faked with a static page.
This is an application, and it carries application-weight responsibilities: a server that runs continuously, a database, software updates, security, backups. That is real, ongoing work - which is exactly why you do not take it on unless the feature earns it.
The trap goes both ways
Most mismatches we are called in to fix are one of two mistakes.
Over-building. A business that needs a fast brochure gets sold a heavy CMS or a custom application "so it can grow." Now they pay to host and maintain machinery they never use, and their simple site ends up slower and more fragile than a static one would have been.
Under-building. A business that genuinely needs bookings or accounts tries to run it on a static page plus a contact form plus a spreadsheet plus a lot of manual coordination. It works for a while - then the double-bookings and copy-paste errors start, and someone's whole afternoon disappears into admin. That was the studio's "before."
The cost of guessing wrong is real either way: wasted money and complexity on one side, drowning in manual work on the other.
A short test you can run yourself
Answer these about the site you have in mind:
- Does a visitor need to log in or have an account?
- Does the site need to remember something specific to each visitor between visits?
- Does what one visitor does change what another visitor sees - a booked slot, stock, a submitted application?
- Is there data that must be stored and queried - bookings, orders, members, submissions?
All "no"? You almost certainly want a fast static site. Save the budget, skip the server, ship something that loads instantly.
Any "yes"? You are in application territory. Build it as a real app from the start - bolting accounts and bookings onto a brochure site later is harder and messier than building for it up front.
The point is not the framework
Astro and Next.js are both excellent. The win was never picking the trendier tool - it was matching the tool to what each site actually has to do. The electrical contractor's site is faster and cheaper to run because it is not pretending to be an app. The studio's platform works because it is not pretending a brochure can handle real bookings.
Get that one decision right, and everything downstream - cost, speed, maintenance, how well it holds up - gets easier.
We build both - fast static sites and full web applications - and we will tell you honestly which one your project needs before you spend a euro on the wrong one. Talk to us.
Frequently Asked Questions
What is the difference between a static site and a web app?
A static site is a set of pre-built HTML pages served as-is to every visitor - no server-side computation per request, no database, no accounts. A web app runs server-side logic on each request and stores data specific to each user (bookings, orders, account history). The deciding question is whether what one visitor does needs to change what the next visitor sees. If yes, you need an application.
When do you need a web app instead of a static site?
You need a web app when visitors must log in, when data must be stored per user (bookings, orders, saved preferences), or when one visitor's action changes what another visitor can do (booking a slot that then disappears from the schedule). If every visitor sees the same pages and the site's job is to inform - who you are, what you do, how to contact you - a static site is the correct choice.
How much faster is a static site than a web app?
A static site has no server-side computation per request. Pages are pre-built files served directly from a CDN, which means sub-second load times on most connections. A web app must execute server logic, query a database, and render a response before anything reaches the browser - typically adding 200ms-1,000ms of server latency before the first byte. For a business site whose job is to earn trust and generate enquiries, that speed difference is a meaningful conversion factor.
Can a static site have a contact form or booking enquiry?
Yes. A contact form or booking enquiry that sends an email does not require the full site to be an application. A single small server endpoint (or a form service like Formspree, Netlify Forms, or a custom Express route) handles the form submission. The rest of the site remains static. Only convert to a full application when you need persistent per-user data - accounts, real-time availability, order history.
What technology should I use to build a static business website?
For a static business site, Astro is a strong choice - it generates zero-JavaScript HTML by default and integrates with React components where interactivity is genuinely needed. Alternatives include plain HTML with a build step, or a React/Vite app pre-rendered at build time. The framework matters less than the principle: no server running, pages pre-built, content served from a CDN. Hosting on Netlify, Vercel, or a Hetzner storage bucket costs close to nothing.