The customer asks.
Checks and does the work.
Keeps the records.
The frontend: the part you can see
Buttons, forms and page layouts usually arrive in a visitor's browser as HTML, CSS and JavaScript. A static host can serve those files. ‘Static’ does not mean the screen cannot be interactive; browser code can still call other services.
Treat anything delivered to the browser as public. Someone can inspect requests and downloaded code without using your interface the way you intended. That matters when deciding where to put credentials and permission checks.
The backend: the trusted work
A backend can check who is allowed to change a record, call a paid AI provider with a private key, verify a payment event or send an email. It may run as a traditional server, a function or part of a full-stack framework.
Some pages also render on a server before reaching the browser. If your project includes that behaviour, hosting only a folder of frontend files can leave important parts behind. Look for server routes and framework configuration, not just a folder named ‘backend’.
The database: the memory
A database stores the records your app needs to remember across visits and releases. Your local screen may already connect to a hosted database. Deploying the frontend does not automatically copy that database or create a safe production version.
Uploaded images and documents often need object storage too. A file written inside a temporary deployment can disappear on restart or replacement. Decide where durable data lives, who can read it and how you will recover it.
Trace one useful action
Imagine an app that turns meeting notes into a summary. The browser accepts the text. A backend checks the account and usage allowance, then calls the AI service. The database stores the result under that user's account. The browser displays it.
Map your own main action in the same way. Beside each step, write the service name, account owner and production setting it needs. If a step has nowhere to run, you have found a deployment gap.
- Where does the customer click or type?
- Where are identity, permissions and spending limits checked?
- Which service does the work?
- Where does the result survive a redeploy?
- Where can you see a failed request?
A few fair questions.
Do I need three separate hosting accounts?
No. One platform can provide multiple parts. Choose based on what your app needs and whether you can understand, maintain and afford the arrangement.
Do all apps need a database?
No. A brochure site or a calculator that keeps no records may not need one. Add storage for a real product requirement, not because every tutorial includes it.
Is my Supabase project the backend?
It can provide database, authentication, storage and other backend capabilities. Your app may still need server-side functions for private API calls or additional business rules. Follow an actual request to see the boundary.