Ask an AI for "a contact form" and you'll get one. Whether it works depends on something you probably didn't specify, and probably didn't know you had to.
There are two kinds of website. Most people only ever need the first, but the second is where the surprises live.
Static: everything happens in the visitor's browser
A static site is files. HTML, images, CSS, and JavaScript that runs on the visitor's device.
That JavaScript can do a lot. Calculators, image galleries, games, filters, animations, charts, a dark mode toggle, a shopping list that remembers what you typed. All of that runs on the phone or laptop of whoever is visiting.
Which means it costs us nothing per visitor, has no timeout, and no limit on how much work it does. If your site is static, you can be as elaborate as you like and nothing will throttle you.
The catch is that when the visitor closes the tab, everything is gone. Nothing was recorded anywhere.
Server-side: something happens on our end
A server-side app runs code when someone visits, on a computer we operate. That lets it do things a browser can't:
- Remember something after the visitor leaves
- Keep a secret, like an API key, without exposing it
- Talk to a database
- Check a password
- Do something on behalf of all your visitors rather than just one
Those are real capabilities, and they cost real money — every visit runs code. That's why they're metered and gated in a way static files aren't.
The test that tells you which you need
Ask this: after the visitor leaves, does anything need to have changed?
If nothing changed, it's static.
| What you asked for | Which it is |
|---|---|
| A page with your hours and a photo | Static |
| A mortgage calculator | Static |
| A gallery you can filter by tag | Static |
| A contact form that opens the visitor's email app | Static |
| A contact form that saves submissions for you to read | Server |
| A booking system | Server |
| Anything with accounts or passwords | Server |
| A page showing live data from somewhere else | Usually server |
That contact form row is the one that catches people. Both are "a contact
form". One is a mailto: link dressed up nicely — no server, works instantly,
free. The other needs somewhere to put what people typed.
If you just want to hear from people, the first is genuinely fine. It's how a lot of small business sites work, and it never breaks.
Why apps need a verified account
Static files sit there. Code runs. Running strangers' code on your own machines is the expensive, abusable thing every hosting platform has to think carefully about — it's how you end up hosting a crypto miner or a phishing page with a login form.
So server-side apps need a verified account. Verification is a $0 card check or a text message. It costs nothing.
The part people get wrong: paying doesn't unlock this. Verifying does. A Pro subscriber who hasn't verified still can't run code, and someone on the free plan who has verified can. Payment is for quota; verification is for proving there's a person behind the account.
If you ask for something that needs a server before you've verified, a well-behaved assistant should tell you before it starts building — not deploy and hit a wall.
What server-side apps can use here
If you do go server-side, a few things are worth knowing up front, because they shape what to ask for.
Packages are curated, not installed from npm. Available: hono,
itty-router, zod, @neondatabase/serverless, @upstash/redis, jose,
bcryptjs, nanoid, uuid, marked, date-fns, ms. Ask for something
outside that list and you'll get an error naming what to use instead.
That sounds restrictive and mostly isn't — it covers routing, validation, a database, a cache, auth and dates. It exists because installing arbitrary packages means running arbitrary install scripts, which is not a thing to do casually.
Each request gets a CPU budget. 10ms on free, 50ms on Starter, 200ms on Pro. That is a lot of computation — it's not 10ms of wall-clock waiting, it's 10ms of actual processing. But heavy work like resizing a large image server-side will hit it. Move that kind of thing to the browser where there's no limit.
No raw network connections. Apps talk to allowlisted hosts over HTTP. That
rules out sending email directly by SMTP and connecting to a database over its
native protocol. Use an email API and a database with an HTTP interface — which
is why @neondatabase/serverless and @upstash/redis are on the list.
Nothing runs in the background. An app responds to requests. It doesn't sit there doing things between them.
Start static
If you're not sure, ask for the static version. It publishes immediately, there's no verification step, and nothing about it limits you later — you can always add a server-side piece once you know you need it.
The most common mistake isn't picking wrong. It's building the complicated
version of something that only needed a mailto: link.