What does my app actually need? Database, login, email and more

When people take an idea from Claude into the real world, they usually either forget something important or add everything just in case. The second is more expensive than it looks, because every service you add has to be paid for, secured and kept up to date, whether anyone uses it or not.

So I start with a simple question: what does this actually have to do? The answer decides most of what you need, and it works the same way for a website, a web app or a phone app.

What an app is made of

Most apps come down to the screens people use, the rules that decide what happens when they do something, and the memory that keeps information for later. The screens are usually called the front end and the rules the back end. Everything else, such as login, email or payments, is a service you plug in around those, and only when you need it.

Four questions that decide most of it

If the answer to all four is no, you have a simple website. Host it, connect your domain and you’re done. It doesn’t need a back end, whatever anyone tries to sell you.

If you’re not sure, Claude can go through it with you.

Database: the app’s memory

A database is where your app writes things down so it can find them again later. Without one, anything a visitor enters is gone as soon as they close the page.

You need one if the app saves bookings, orders, accounts or messages, or anything that one person enters and someone else needs to see. You don’t if it’s a page of information, or a tool that does its work on the spot, like a calculator.

For most projects I’d use a hosted PostgreSQL database from a provider such as Supabase or Neon. They run the server, handle the updates and keep it available, so you don’t have to.

Login: proving who someone is

Login is usually called authentication, or auth, and it checks who someone is. It goes hand in hand with authorisation, which decides what that person is allowed to do. A customer can see their own orders, for example, but only you can see everyone’s.

You need it if people have private information, or if different people are allowed to do different things. You don’t if everything is public. Plenty of useful apps have no accounts at all, and every login screen is one more password for people to forget.

Don’t build the password side yourself, and don’t let Claude build it from scratch either. Use an established service such as Clerk, Auth.js or Supabase Auth. Password storage, “Sign in with Google”, resets and two-step verification are all easy to get wrong in ways that aren’t obvious until someone exploits them.

Payments: let a specialist hold the money

If you take money online, use a provider such as Stripe and send customers to its hosted checkout. Card numbers never touch your server, so that risk and most of the compliance work sit with Stripe. What you still need to do is record what each payment was for, which means you’ll need a database too.

Email: the part that ends up in spam

You need it if you send receipts, reminders, password resets or contact form messages. Use a service built for automated email, such as Resend or Postmark, rather than a personal Gmail account.

Getting the emails delivered is the harder part. Your domain needs three DNS records, SPF, DKIM and DMARC, which together show receiving mail servers that the email really came from you. You don’t need to understand them in depth. Your email service gives you the values and you add them to your domain’s DNS settings.

Caching: remembering answers to go faster

A cache keeps a copy of an answer so it doesn’t have to be worked out again. If a thousand people request the same page, you build it once and serve the copy, which is faster and cheaper. Your host already does a lot of this through its CDN, a network of servers that keep copies of your pages close to your visitors.

The risk with caching is serving out-of-date information, like yesterday’s price. I’d leave it alone at the start and only add more when you can see something is actually slow. If Claude adds caching anyway, ask it to explain what’s being cached, for how long and what clears it.

File storage: where uploads go

If people upload photos or documents, those files don’t go in the database. They go in file storage, such as Cloudflare R2 or Supabase Storage, and the database keeps a record of where each one is. If the files are private, check that only the right people can open them, because storage buckets left public by mistake are an easy way to leak data.

What it costs, in pounds and dollars

Most of these services are free until you have real users, then cheap. This is roughly what I’d expect to pay for a small business app. Prices were checked in November 2026, and the exchange rate is rounded, so confirm on each pricing page before you commit.

So a first version often costs nothing but the domain, and a busy small-business app with a database, email and login typically lands around £35 to £60 ($45 to $75) a month. Stripe’s cut comes out of each sale rather than your monthly bill.

Write it down before you build

Once you’ve decided, get Claude to put it all on one page. It stops extra features creeping in later, and if you bring in a developer at some point, it’s the first thing they’ll want to see.

Next, read how to put it on the web, and the checks to run before you launch.

If you’re still not sure what you need, that’s normal. Tell me what you’re trying to do and I’ll tell you what I’d build and what I’d leave out. See my services, or get in touch for a free 20-minute call.