From Website to Web App: When Does Your Site Need User Login and a Database?

A website with user login and a database is really a web app, and making that switch changes your budget, your running costs and your responsibility for other people's data. You need it when different users have to see or change their own information: orders, documents, bookings or content they've paid for. If every visitor sees the same content, you don't need a login, however large the site gets.

I build both websites and web apps, so keep that in mind as you read. Plenty of requests that start as "customers should be able to log in" can be handled with a form or a hosted tool, and I'll point those out.

The short answer

The deciding question isn't how advanced the site should be. It's whether different users need to see different data. Here are the requests I hear most often, and whether they actually need login and a database.

My rule is short. Do different users need to see data that changes over time and that only they are allowed to see? Then you're building a web app. If not, you have a website, perhaps with a few hosted tools plugged in. If you're already planning a full platform, my guide to building your own platform compares the four routes: off-the-shelf SaaS, no-code, coding it yourself or hiring a developer.

Website, website with hosted tools, or web app?

People use these words loosely, so here's how I draw the lines. There are three levels, and most businesses only need the first or second.

A website

Every visitor sees the same content. You and your team log in to a CMS (the content management system where you edit text and images), but that login is for editors only. Hosting is cheap, and the only customer data on the site is whatever comes in through forms.

A website with hosted tools

The site borrows features from other services: a booking tool, a payment link, a newsletter form or a chat widget. Users might create an account, but the account and their data live with the vendor. You pay a subscription, and the vendor handles security.

A web app

Now the site has its own users and its own database (the structured store where the system keeps users, orders and everything else that changes). Authentication tells the system who a user is. Permissions decide what that user can see and do. Every page is built for the person asking, so the code has to run on a server instead of being served as ready-made files.

The jump from the second level to the third is where the cost sits. Not because a login form is hard to build, but because everything around it has to be built, tested and looked after.

How to decide in five steps

Work through these before you ask anyone for a quote. They take an afternoon and can save you from a project you didn't need.

1. Write down what users should be able to do after logging in. Phrase three to five tasks in their words: "download my latest invoice", "upload my documents", "book or cancel a slot". If you can't write them, you don't need a login yet.
2. Map which data has to be stored and where it lives today. If it already sits in your accounting software, CRM or a spreadsheet, the real project is often an integration with something like Xero or HubSpot, not a new database. Note whether it includes personal data, because under GDPR that makes you the controller for it.
3. Check whether a hosted tool can do the job. Gated content and subscriptions are easy to buy, and my guide to building a membership platform with login and payments shows where off-the-shelf stops. If clients need to see their own cases and files, compare a custom client portal with a white-label one before you commit.
4. Price the build and the running costs. A web app comes with a yearly bill a brochure site doesn't have. The next two sections give you rough numbers.
5. Decide how the website and the app will fit together. Should the login live inside your current site, or should the app be a separate system next to it? That choice affects cost, search visibility and who can change what.

What the jump does to your budget

The table shows my rough estimates for 2026, excluding VAT, for work by an experienced freelance developer in Western or Northern Europe. The ranges are wide because scope varies a lot.

Screen count rarely drives the price of a web app. User types and permissions do, along with integrations, payments and how much has to work on day one. A client portal where people only read their own documents costs far less than one where they also order, pay and invite colleagues. My web app cost guide breaks the three price tiers down further.

The line people forget is the recurring one. A website can sit more or less untouched for a couple of years. A web app with users can't, because security patches, new browser versions and changes in the services it talks to need steady attention. If the app cost €35,000, my 10-20% rule of thumb means €3,500-7,000 a year before any new features.

What changes in day-to-day operations

Once users log in, responsibility shifts to you. You're the one your users hold accountable when something breaks, even if a vendor caused it. Five areas need an owner from day one.

1. Security. The login is your front door. Passwords must be stored hashed (so they can't be read even if the database leaks), repeated login attempts must be throttled, and two-factor authentication should be available. The OWASP Authentication Cheat Sheet sets out what good looks like. Don't build authentication from scratch: Laravel's starter kits, for example, ship with login, password reset, email verification and two-factor authentication.
2. Personal data. Under GDPR, storing user information makes you the data controller. You need to explain what you store and why, delete it on a set schedule, and sign a data processing agreement with every processor that handles the data for you, such as your hosting provider and, if they can access the data, your developer. The EDPB's guide for small businesses on controllers and processors lists what that contract must cover. This isn't legal advice, so talk to an adviser if you handle sensitive data.
3. Backups and monitoring. The database is now the most valuable part of the system. It needs automatic backups, a restore you've actually tested, and alerts that reach a person when the app goes down.
4. Support. "I can't log in" becomes a new kind of support request. Someone has to help users, reactivate locked accounts and delete accounts on request.
5. Updates. The framework, packages and server need regular updates. That's the work the 10-20% a year pays for.

When you shouldn't build your own login

The cheapest login is one you don't have to maintain. I usually advise against a custom build when:

• a hosted tool covers most of the need. Booking, newsletters, member content and simple client areas are all available as subscriptions, and adapting your process to the tool is usually cheaper than the reverse.
• only a handful of clients need to see documents. A shared folder with proper access control, or an email with a secure link, can carry you a long way.
• you haven't tested demand. Deliver the service by hand to your first customers, and build once you know what they actually use.
• the budget covers the build but not the upkeep. A web app nobody maintains turns into a security risk.

If you're already on WordPress, a membership plugin can handle a simple gated area, and a WordPress developer will be cheaper than me for that job. I've written about where the line falls in WordPress vs a custom-coded website. And if you'd like to build a first version yourself, no-code tools get further than most people expect. My post on the limits of no-code app builders like Bubble, Softr and Glide shows where the ceiling usually is.

How the website and the web app fit together

Once you know you need a web app, the next question is whether it lives inside your website or next to it. There are two common setups.

One system works when the gated part is small and tied closely to your content, such as a members' area with articles in the same CMS as the rest of the site. It's the cheapest way to start, but the CMS sets the limits on what the app can do.

Two systems is my default for a real web app. The marketing site sits on yourcompany.com and can run on whatever CMS suits your marketing team, while the app lives on app.yourcompany.com with its own code, database and hosting. You can redesign the website without touching the app, and ship app updates without risking your sales pages. With shared colors, fonts and a "Log in" button in the menu, users experience it as one place.

Two things apply either way. Search engines don't log in, so anything behind a login generally won't show up on Google, and the pages that sell need to stay public. And your privacy policy has to cover the app as well as the website, because the app stores far more than a contact form ever did.

Next steps

Run through this checklist before you speak to a developer or vendor. It makes the quotes you get back much easier to compare.

If a hosted tool can do the job, start there. If it needs building, I start larger projects with a paid, fixed-price discovery phase, where I work through users, data and integrations with you and hand over a plan and a price. You deal directly with me, the developer writing the code, and you own the code from day one. See how I approach custom web apps with user accounts and your own data.

Frequently asked questions

Can I launch a website now and add user login later?+

Yes, and it's often the right order. Build the website you need today, then add the web app once the demand is proven. If the site runs on a framework such as Laravel or Next.js, login can go into the same codebase later. If it's built on Wix, Squarespace or Webflow, the app becomes a separate system next to it, which is rarely a problem.

Can users sign in with Google, Microsoft or a national eID?+

Yes. Google and Microsoft sign-in use open standards that most modern frameworks and auth services support. It saves users another password and saves you support time, and Microsoft sign-in suits B2B apps whose users work at other companies. National eIDs such as BankID in Sweden or MitID in Denmark usually go through an identity broker with its own costs and requirements, so they're mainly worth it when you must verify who someone is.

Should I use the framework's built-in login or a hosted auth service?+

The framework's built-in authentication is enough for most projects, and it keeps user data in your own database. A hosted service such as Auth0, Clerk or WorkOS is worth a look when enterprise clients expect single sign-on with their company accounts, or when several apps share one login. The trade-off is another vendor, a bill that can grow with your user count, and one more processor to cover in your GDPR paperwork.

Where should the data behind a website with user login be hosted?+

Inside the EU is the safest default. It keeps GDPR simpler because personal data doesn't leave the EU, and most large hosting providers offer EU regions such as Frankfurt or Dublin. Don't stop at the main server, though. Backups, transactional email and error tracking also process user data, so check where those services store it and list them in your processing agreements.

Who owns the code and the user data if a developer builds it?+

Whoever the contract says, so put it in writing. You should own both the code and the data, and the database should sit in a hosting account in your company's name so you can change developers without losing anything. With me, you own the code from day one. On a hosted tool the data lives with the vendor, so check how you'd export it before you sign up.