How passo.build thinks about your app
passo.build does not ask you to choose an architecture pattern. It asks what the product needs to do, then derives the shape from the repository and your answers:
- Is there a user-facing frontend?
- Does the app store data?
- Does it upload files or media?
- Does it need sign-in, roles, teams or tenants?
- Does it call paid or private APIs?
- Does it need background jobs, scheduled work, webhooks or queues?
- Does it need realtime updates or specialised processing?
The default split
For most products the safe default is:
| Area | Rule |
|---|---|
| Website or app shell | Hosted cheaply as a managed frontend with CDN, TLS and rollback. |
| APIs and business logic | Private logic stays server-side, behind authenticated APIs. |
| Database | Durable data lives in a managed database. |
| Files | File contents go to object storage; metadata and permissions stay in the database. |
| Secrets | Never in the browser, never in the repository. Server-side environment or secret storage only. |
| Jobs | Work that should not happen during a browser request goes to a worker, queue or scheduler. |
| Auth and roles | An identity provider plus explicit server-side permission checks. |
| Logs and monitoring | Enough to debug deploys, API failures, auth failures and cost surprises. |
Examples
| What the repository shows | What passo.build proposes |
|---|---|
| Static site or frontend-only prototype | Managed frontend hosting. No database unless the product stores data. |
| CRUD app with users and records | Managed frontend, authenticated API, managed database, backups, logs. |
| App with image or video uploads | The above, plus object storage for the files. |
| App with scheduled email, imports or webhooks | The above, plus a worker or scheduler with retries. |
When the signals conflict or are missing, passo.build asks a question before it commits to a shape. The proposal explains why the shape fits the product and what evidence must exist before release.