You Don't Always Need a Backend, a Database, or a Login

Not every web tool needs a server, a database, and user accounts. Sometimes the simplest, cheapest, and most secure option is the one with no backend at all.

A lot of project briefs I get start with "we'll need accounts, and a database to store X." Sometimes that's true. Often it's the default assumption, not an actual requirement — and skipping it entirely is the better call.

The tool that has no server

CraftNet is a crafting cost-and-profit calculator I built for a FiveM roleplay server. Players price out a build from a set of recipes, get a shortfall-aware bill of materials, and share the exact result with someone else — no account, no login, no database. The entire state of a build — the queue, the prices, the stock on hand — gets encoded straight into the URL. Open the link, and you're looking at the same build, reconstructed entirely in the browser.

There's nothing to host beyond static files, nothing to back up, and nothing that can leak because there's no user data sitting anywhere to leak.

Why "no backend" is sometimes the better architecture, not the cheaper one

It's tempting to read "no backend" as a budget compromise. For the right kind of tool, it's the more correct choice on its own merits:

• Nothing to secure that isn't already secured. No login means no login to break into, no session to hijack, no password database to leak.
• Nothing to keep running. A static tool doesn't go down because a server or database had a bad night. It's exactly as available as the CDN serving it.
• State that's actually shareable. Encoding state in the URL — instead of behind a login — means "send someone the result" is free, instant, and doesn't require them to have an account either.

When you do need one

This isn't an argument against backends — plenty of the case studies here (Navarro's dealership stack, Southside Records' admin CMS) genuinely need a database, real auth, and server-side logic, because the data has to persist, be private, or be shared across sessions and users. The tell is usually: does this need to remember something after the tab closes, and does more than one person need to see the same version of it? If yes to either, you need a backend. If the honest answer is "no, it's really just a calculation over some inputs," you might not.

The takeaway

Before a project defaults to "web app with accounts and a database," it's worth asking whether the thing being built actually needs to persist or restrict anything. A tool that computes something from inputs and hands back a result doesn't need a login just because most software has one. Fewer moving parts is fewer things that can break, leak, or cost money to run.

Not sure which category your idea falls into? Get in touch or see how I scope projects — figuring that out up front is part of the job.