One complete example

This example shows how passo.build should feel from the first repo connection to the deploy gate.

The app

You built a small marketplace with a coding agent:

• a Next.js frontend;
• user accounts;
• seller profiles and listings;
• image uploads;
• Stripe checkout;
• email notifications;
• an admin page for disputes.

The prototype runs locally, but production is unclear. The repo has some API routes, a few environment variables, and generated UI code, but no complete deployment plan.

Step 1: repository

You connect the repo. passo.build records the repository, branch, and product brief. If the code does not make the product obvious, the brief fills the gap:

"A two-sided marketplace where sellers publish listings and buyers purchase through Stripe. Sellers upload images. Admin users resolve disputes."

Step 2: product scope

passo.build combines repository signals with your answers.

It detects:

• a browser frontend;
• API routes;
• Stripe usage;
• image upload UI;
• login screens;
• no durable production database configuration;
• no object storage configuration;
• no clear background job or email retry path.

It asks missing questions in plain language:

Question	Why it matters
Will users create accounts?	Determines auth, sessions, roles, and user data.
Are listings and purchases stored permanently?	Requires a managed database and backups.
Do images need to be private or public?	Determines storage, permissions, and signed URLs.
Should emails retry if the provider is down?	Determines queue or background job needs.
Is there an admin role?	Requires server-side authorization checks.

The output is not just advice. It becomes implementation work for the coding agent:

• create or verify a managed database schema for users, sellers, listings, purchases, disputes, and audit events;
• move private Stripe and email calls behind server-side APIs;
• store uploaded images in object storage and metadata in the database;
• add role checks for seller, buyer, and admin actions;
• add health checks, structured logs, and deployment environment variables;
• add tests for auth, listing creation, checkout callback, and upload metadata.

Step 3: security

Security runs after scope is clear. The point is to check the real product, not a half-defined prototype.

Typical blockers:

• API keys in frontend code or committed files;
• webhook handlers without signature verification;
• admin actions without server-side role checks;
• uploads without file-type and size limits;
• missing dependency or build evidence.

If a blocker appears, the right output is a task for the coding agent, a PR, and evidence. Deploy waits.

Step 4: architecture

passo.build proposes the smallest production shape that fits the product:

Need	Selected shape
Browser app	Managed frontend hosting with CDN, TLS, preview builds, rollback.
User and marketplace data	Managed PostgreSQL database.
Image files	Object storage; database stores metadata and permissions.
Private Stripe/email logic	Server-side API.
Webhooks and retries	API endpoint plus background job or queue when needed.
Secrets	Server-side environment or secret storage, never browser code.
Logs	Structured API and deploy logs.

The user does not need to know the name of an architecture pattern. They only need to see that every product requirement has a safe runtime home.

Step 5: compare and deploy

Compare uses the accepted architecture, region, sizing, account mode, and spend cap.

Before anything changes cloud resources, passo.build should show:

• provider and region;
• estimated monthly cost and assumptions;
• what is included and excluded;
• whether the account is bring-your-own or PyxCloud Managed;
• which gates passed;
• rollback or teardown path;
• explicit human confirmation.

Deploy is ready only when the implementation work has evidence and the controller accepts the gates.

What good output looks like

A good passo.build run leaves you with:

• a clear product scope;
• an implementation plan a coding agent can execute;
• security findings tied to code changes;
• an architecture that matches the product;
• cost comparison with assumptions;
• evidence links;
• a deploy decision the user can understand.

If any of those are missing, the correct next step is more implementation or evidence, not a faster deploy.