How passo.build thinks about your app
passo.build does not start by asking you to choose an architecture pattern. It starts by asking what the product needs to do.
From the repo and your answers, it looks for practical signals:
- Is there a real user-facing frontend?
- Does the app store data?
- Does it upload files or media?
- Does it need login, roles, teams, or tenants?
- Does it call paid or private APIs?
- Does it need background jobs, scheduled tasks, webhooks, or queues?
- Does it need realtime updates, AI/media processing, or another specialized runtime?
- Does it have production users, compliance needs, backups, logs, or incident response expectations?
Those answers drive the deployment plan.
The default split
For most products, the safe default is:
| Area | Plain-English rule |
|---|---|
| Website/app shell | Host it cheaply as a managed frontend with CDN, TLS, previews, and rollback. |
| APIs and business logic | Keep private logic server-side, behind authenticated APIs. |
| Database | If the product stores durable data, use a managed database unless there is a strong reason not to. |
| Files | Store file contents in object storage; keep metadata and permissions in the database. |
| Secrets | Keep secrets out of the browser and out of the repo. Use server-side environment or secret storage. |
| Jobs | Use a worker, queue, cron, or managed scheduler when work should not happen during a browser request. |
| Auth and roles | Use an identity provider and explicit server-side permission checks. |
| Logs and monitoring | Produce enough evidence to debug deploys, API failures, auth failures, and cost surprises. |
This is the part users need to understand. The implementation may use technical terms later, but those terms should serve the product decision, not lead it.
Examples
| What the repo/product shows | What passo.build should recommend |
|---|---|
| Static marketing site or frontend-only prototype | Managed frontend hosting. No database unless the product actually stores data. |
| CRUD app with users and records | Managed frontend, authenticated API, managed database, backups, logs. |
| App with image/video uploads | Managed frontend, API, managed database for metadata, object storage for files. |
| App with scheduled email, imports, or webhooks | API plus background jobs/queue/scheduler, with retry and audit trail. |
| App builder backend that is getting expensive | Check whether data/API pieces can move to PostgreSQL-first infrastructure; refuse that path when media, realtime, AI, or long-running jobs need specialized services. |
How passo.build decides
passo.build should not pick a cloud shape because one pattern is fashionable. It maps product signals to runtime needs.
| Signal | Decision pressure |
|---|---|
| Durable user data | Use a managed database, with backups and migration evidence. |
| File uploads | Use object storage for file bytes and database rows for metadata, owners, and permissions. |
| Browser-only static content | Keep it on managed frontend hosting; do not invent a backend. |
| Private API keys or paid APIs | Move calls server-side and keep secrets out of browser code. |
| Webhooks, imports, email retries, scheduled work | Add a worker, queue, cron, or managed scheduler. |
| Realtime/media/AI-heavy work | Do not force a database-only answer; use the specialized runtime the product actually needs. |
| Admin roles, teams, tenants | Require server-side authorization checks and audit evidence. |
When signals conflict or are missing, passo.build should ask a question before it commits to an architecture. A good recommendation explains why the selected shape fits the product and what evidence must exist before deploy.
Developer note
Internally, this is the same invariant as "keep the presentation layer separate from the API/business/data layer." The docs avoid leading with that vocabulary because most users care about the outcome: a product that is cheaper, safer, and deployable.