# Architect Agent
Source: https://productos.dev/docs/agents/architect
An optional system design specialist that turns your PRD into architecture documents, decision records, and infrastructure cost estimates.
The Architect Agent is the optional technical deep-dive inside the Define stage. Its system prompt describes it as "a system design and technical architecture specialist." From the PRD and your locked constraints it produces real architecture documents across eight sections: system overview, container architecture, database and API design, deployment and security architecture, design patterns, and technical risks.
It records architecture decisions as ADRs and can estimate infrastructure cost, so the build that follows starts from decisions, not defaults. One boundary worth knowing: it designs the system; it does not write the app code. Implementation belongs to the [Fullstack Builder](/docs/agents/fullstack-builder).
## Tools
| Tool | What it does |
| ------------------------------ | --------------------------------------------------------------- |
| `write_architecture_section` | Writes one of eight architecture sections, the main deliverable |
| `record_architecture_decision` | Captures an ADR with context and consequences |
| `estimate_infrastructure_cost` | Projects the running cost of the proposed architecture |
| `load_constraints` | Reads locked tech-stack facts and project constraints |
## What it reads and produces
**Reads:** PRD sections; structured project constraints; locked tech-stack facts.
**Produces:** eight architecture sections, from system overview to technical risks; architecture decision records; infrastructure cost estimates.
## Where it sits in the pipeline
The Architect Agent lives inside Stage 3, Define, alongside the [PRD Agent](/docs/agents/prd), and it is optional: projects that do not need a formal architecture pass skip it entirely. When you do run it, the [Orchestrator](/docs/agents/orchestrator) scaffolds the architecture outline with `setup_architecture_outline` and delegates sections the same way it does for the PRD. From there the pipeline continues into Stage 4 with the [Design Agent](/docs/agents/design).
## When to use it
Skip it for simple products where the default stack is fine. Reach for it when the technical shape of the product is a real decision: multi-service systems, non-trivial data models, security or compliance requirements, or anything where you want infrastructure cost projected before you build.
Lock your constraints before invoking it. The agent's first move is `load_constraints`: it reads your locked tech-stack facts and project constraints and designs within them. If you have a required database, hosting target, or compliance boundary, get it into the project constraints first; stating it mid-conversation after the sections are written means revising decisions that are already recorded as ADRs.
# Deploy Agent
Source: https://productos.dev/docs/agents/deploy
Owner of the publish pipeline: preflight build, GitHub push, Vercel deploy, and up to three self-fix iterations to a live URL.
The Deploy Agent takes the built project out of the sandbox and ships it. Its system prompt names the mandate: "Owner of the publish-and-deploy pipeline for a single project." It runs a preflight production build, pushes the code to GitHub, creates or reuses the Vercel project, syncs environment variables, and polls the deployment to completion.
When a build breaks, it applies up to three targeted fix iterations before asking you, and it keeps a cumulative deploy ledger so every release is accounted for. The result is your product live on its own URL, with the code in a repo you own. Projects ship to `{slug}.product-os.app`, or to a custom domain.
## Tools
| Tool | What it does |
| -------------------------------------------------- | ---------------------------------------------------------- |
| `check_recent_deploy` | Mandatory first call: checks the current deployment state |
| `preflight_build` | Runs the production build in-sandbox before anything ships |
| `push_to_github_org` | Pushes the codebase to GitHub |
| `trigger_vercel_deploy` / `poll_vercel_deployment` | Creates the Vercel deployment and follows it to completion |
| `read_vercel_build_logs` | Diagnoses failed builds for targeted fixes |
## What it reads and produces
**Reads:** the built project in the sandbox; environment variables; the deployment target.
**Produces:** a live production deployment on its own URL; a GitHub repo with your code; a cumulative deploy ledger.
## Where it sits in the pipeline
Deploy is an on-demand action, not a stage: you trigger it whenever you want to ship, and you can redeploy as often as you like. It is the last agent in the chain, downstream of the [Fullstack Builder](/docs/agents/fullstack-builder) that wrote the code and, ideally, a passing run from the [QA Agent](/docs/agents/qa). The [Orchestrator](/docs/agents/orchestrator) can also poll live deployment state directly with `check_deploy_status`, so you can ask about a release without triggering a new one.
The sequence is deliberately defensive. `check_recent_deploy` runs first so the agent never deploys blind over an in-flight or just-finished release, and `preflight_build` runs the production build inside the sandbox before anything is pushed, so most failures are caught and fixed before they ever reach Vercel.
For domains and deployment details beyond the agent itself, see [deployments and domains](/docs/platform/deployments-and-domains).
## Working with it
Run the [QA Agent](/docs/agents/qa) before you deploy. The Deploy Agent's self-fix loop is scoped to build failures: it reads the Vercel build logs and repairs what breaks compilation, up to three iterations. It does not judge whether your signup flow works. A QA pass first means the thing that goes live is verified end to end, not just buildable.
# Design Agent
Source: https://productos.dev/docs/agents/design
A UI/UX specialist that turns your concept, research, and PRD into user flows and screen specifications for the product you defined.
The Design Agent reads everything the earlier stages produced, the concept, the research, and the PRD, and turns it into user flows and UI screen specifications. Its system prompt frames it as "a product design specialist focused on brand identity, user flows, and UI screen specifications." Because it designs from the actual spec, the screens are for the product you defined, not a generic template.
It keeps your workspace in sync while it works, switching the active design tab as it moves through brand, flows, and screens, and it hands token and component-system work to the [Design System Agent](/docs/agents/design-system).
## Tools
| Tool | What it does |
| ---------------------------------------------- | ------------------------------------------------------------------------- |
| `write_design_doc` | Writes brand, flow, screen, and report documents, the primary deliverable |
| `get_user_flows` / `set_user_flows` | Reads and updates the project's user-flow diagrams |
| `get_brand_guidelines` / `generate_mood_board` | Works with the locked brand direction and visual references |
| `ask_agent` | Consults the Design System Agent or upstream agents |
## What it reads and produces
**Reads:** the concept and research; the PRD; the locked brand direction.
**Produces:** user-flow diagrams; UI screen specifications; design documents and reports.
## Where it sits in the pipeline
The Design Agent opens Stage 4, Design, taking over from the [PRD Agent](/docs/agents/prd) (or the [Architect Agent](/docs/agents/architect), if you ran the optional architecture pass). It works alongside the [Design System Agent](/docs/agents/design-system) in the same stage: this agent owns flows and screen specs, that one owns tokens, components, and DESIGN.md. Its screen specifications are what the [Fullstack Builder](/docs/agents/fullstack-builder) implements in Develop.
## Working with it
The agent designs against two anchors: the PRD and the locked brand direction. The PRD comes from the previous stage; the brand direction comes from brand setup, which the [Orchestrator](/docs/agents/orchestrator) can run automatically (palette, font pairing, vibe report).
Settle the brand direction before the screens. The agent reads the locked brand guidelines through `get_brand_guidelines` and designs every screen against them, so a brand change after the fact ripples through every flow and spec. If you have strong visual opinions or reference products, get them into the brand direction first; asking for a mood board is a cheap way to check alignment before any screens exist.
# Design System Agent
Source: https://productos.dev/docs/agents/design-system
A senior visual designer that builds your design tokens, component system, and DESIGN.md, with real dark and light HTML previews.
The Design System Agent is a senior visual designer that crafts cohesive, production-ready design systems benchmarked against Linear, Vercel, Stripe, Notion, and Apple's Human Interface Guidelines. Its system prompt captures the sensibility: "Restraint over flourish. Personality you can name."
From your locked brand it builds the canonical design tokens, the component system, and a DESIGN.md brief. It renders real dark and light HTML previews of the system before any product code exists, and its output is the token source every downstream build agent works from. This is why shipped ProductOS products look designed rather than generated.
## Tools
| Tool | What it does |
| ------------------------------------------ | ------------------------------------------------------------- |
| `write_design_preview` | Renders dark and light HTML previews of the design system |
| `write_design_brief` | Writes DESIGN.md, the canonical token and component brief |
| `grep_design_brief` / `patch_design_brief` | Searches and surgically edits the brief as the system evolves |
## What it reads and produces
**Reads:** locked brand guidelines and uploaded assets; the mood board and vibe report; PRD personality notes.
**Produces:** DESIGN.md and a compact design brief; dark and light preview pages; the token source for every build agent.
## Where it sits in the pipeline
The Design System Agent works in Stage 4, Design, alongside the [Design Agent](/docs/agents/design). The division of labor: the Design Agent owns user flows and screen specifications, this agent owns the visual system underneath them, and the Design Agent hands token and component work over via `ask_agent`. Downstream, the [Fullstack Builder](/docs/agents/fullstack-builder) implements every screen on the tokens locked in DESIGN.md, so what this agent decides is what your shipped product looks like.
## Working with it
Its inputs are entirely visual and brand-side: locked brand guidelines, uploaded assets, the mood board, the vibe report, and any personality notes in the PRD. The more real material it has, the less generic the system.
Review the dark and light previews before moving to Develop. They are real rendered HTML, not mockups, and they exist precisely so you can judge the system before any product code depends on it. Requesting token changes at this point means a surgical `patch_design_brief` edit; requesting them after the Fullstack Builder has implemented twenty screens on those tokens means rework.
# Fullstack Builder
Source: https://productos.dev/docs/agents/fullstack-builder
The implementation agent: a full coding agent running headless inside your project sandbox, writing the codebase your PRD specifies.
The Fullstack Builder is the implementation agent: a full coding agent running headless inside your project's live sandbox, editing files and running commands directly against a pre-installed Next.js project. In the Design stage it appears under the Frontend Engineer label; in Develop it builds the whole stack.
It consumes the design system tokens and the PRD, so the code it writes implements the product you specified, screen for screen, on the tokens your Design System Agent locked. The system draws a hard boundary here: the Orchestrator is forbidden from writing code itself. As its prompt puts it, "Code belongs to the Develop sub-agent."
## Tools
| Tool | What it does |
| ---------------------------- | --------------------------------------------------------------------------------- |
| Full sandbox toolset | Reads, writes, and edits files and runs shell commands inside the project sandbox |
| `delegate_to_develop_fix` | Receives targeted auto-fix runs generated from QA findings |
| `dispatch_to_design_builder` | Runs live Next.js builds in the Design Builder tab during the Design stage |
## What it reads and produces
**Reads:** design system tokens and DESIGN.md; the PRD; a concrete build task.
**Produces:** the application codebase in your sandbox; a live dev preview as it builds.
## Where it sits in the pipeline
The Fullstack Builder owns Stage 5, Develop, downstream of the [Design System Agent](/docs/agents/design-system) whose tokens it builds on. It also makes a cameo in Stage 4, where it runs live builds as the Frontend Engineer. Once it has built, the on-demand [QA Agent](/docs/agents/qa) verifies the result, and QA failures can chain straight back into this agent as a targeted auto-fix run through `delegate_to_develop_fix`.
The code it writes is yours: generated code syncs to your own GitHub repo as it is written, with full export and no lock-in. See [code ownership](/docs/platform/code-ownership).
## Working with it
The agent works from a concrete build task, not a vibe. The [Orchestrator](/docs/agents/orchestrator) delegates tasks scoped against the PRD, and the design system tokens are already locked before it starts, so the biggest lever you have is the quality of the upstream artifacts.
Watch the live preview while it builds rather than waiting for the end. The sandbox serves a live dev preview as the agent works, and catching a wrong direction on the second screen is a one-line correction; catching it after the whole app is built is a rework request. For anything that already shipped, pair it with the [QA Agent](/docs/agents/qa) and let the fail verdict trigger the auto-fix loop instead of describing bugs by hand.
# Ideation Agent
Source: https://productos.dev/docs/agents/ideation
A Socratic thinking partner that sharpens your raw idea into a testable concept by asking questions, not writing answers for you.
The Ideation Agent turns a raw idea into a sharp, testable product concept, and it does that by asking rather than writing. Its system prompt is explicit: "You are a QUESTIONER who draws the concept out of the user." It is not a writer who invents concepts for you; it draws the concept out of you, surfaces the assumptions you are making, and logs the open questions that research needs to answer.
The result is a concept brief that states the problem, the target user, and what must be true for the product to work, before any money or build time is spent.
## Tools
| Tool | What it does |
| ----------------------- | ----------------------------------------------------------------- |
| `log_open_question` | Records an unresolved question for later stages to answer |
| `log_assumption` | Records an assumption the concept depends on |
| `ask_agent` | Consults a peer agent, typically Research, for a quick fact-check |
| `web_search` | Checks a claim against the live web while you talk |
| `write_markdown_output` | Maintains the rolling concept brief |
## What it reads and produces
**Reads:** your raw idea; any prior concept brief; the project wiki.
**Produces:** a concept brief covering the problem, the target user, and the assumptions the concept depends on; an open-questions log for the Research Agent.
## Where it sits in the pipeline
The Ideation Agent owns Stage 1, Ideate. It is the first specialist the [Orchestrator](/docs/agents/orchestrator) delegates to when you start a project. Its two structured outputs feed directly into the next stage: the assumptions and open questions it logs become the [Research Agent's](/docs/agents/research) work queue in Discover.
## Working with it
Because the agent is a questioner, the quality of the ideation stage tracks the quality of your answers. It will probe the problem, the user, and the assumptions underneath your idea; vague answers produce a vague brief.
"I don't know" is a useful answer here. When you genuinely do not know something, say so instead of guessing: the agent logs it as an open question or an assumption, and the Research Agent picks it up in the next stage with real evidence. Guessed answers, by contrast, get baked into the concept brief as if they were facts.
# Orchestrator
Source: https://productos.dev/docs/agents/orchestrator
The agent you actually talk to. It runs the full idea-to-deploy pipeline and routes every task to the right specialist agent.
The Orchestrator runs the whole pipeline and routes work to every specialist. It is the agent you actually talk to: it moves your project stage by stage while keeping a clean project wiki, and it never does the domain work itself. Its own system prompt puts it bluntly: "Ideation, research, PRDs, design, code: delegate."
Every research question, PRD section, design decision, and line of code is routed to the right specialist. The Orchestrator is the only path between stages and the connective tissue of the whole system: it scaffolds outlines before delegating sections, proposes stage transitions for your approval, runs brand setup in automatic mode, and reads memory across every agent so nothing agreed in one stage gets forgotten in the next.
## Tools
| Tool | What it does |
| --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| `delegate_to_*` | Hands a task to any specialist: ideation, research, PRD, architect, design, design system, QA, deploy, or the fullstack builder |
| `setup_prd_outline` / `setup_architecture_outline` | Scaffolds document outlines before per-section delegation |
| `get_stage` / `set_stage` / `propose_stage_transition` | Reads and advances the project through the pipeline |
| `check_deploy_status` | Polls Vercel directly for live deployment state |
| `generate_brand_palette` / `generate_font_pairing` / `generate_vibe_report` | Runs automatic brand setup for the project |
| `exa_search` / `scrape_url` / `crawl_site` / `gemini_search` | Web research, page extraction, and grounded search |
| `ask_user` | Asks you a bounded question when a decision genuinely needs a human |
## What it reads and produces
**Reads:** your idea, requests, and attachments; the full project wiki; cross-stage memory from every agent.
**Produces:** stage transitions across the pipeline; a rolling progress ledger; a clean, current project wiki.
## Where it sits in the pipeline
The Orchestrator is not a stage; it spans all of them. It is active from your first message in Ideate through the moment the [Deploy Agent](/docs/agents/deploy) ships your product, and it is the only agent that talks to you at any point. The first specialist it typically delegates to is the [Ideation Agent](/docs/agents/ideation).
Stage transitions are never silent. When the Orchestrator believes a stage is done, it proposes the transition and waits for your approval before moving on.
Talk to the Orchestrator in terms of outcomes, not agents. You do not need to name a specialist; say what you want ("compare the top three competitors' pricing", "add a settings page") and the Orchestrator routes it. If you do want a specific agent involved, asking for it works too: delegation is its entire job.
# The AI product team
Source: https://productos.dev/docs/agents/overview
Meet the ten specialized agents behind ProductOS: what each one does, the order they work in, and how they share one project context.
ProductOS is built around a team of specialized AI agents. You describe your idea once; the team researches it, writes the PRD, designs it, codes it, and deploys it. Each agent is narrow on purpose: it has its own system prompt, its own tools, and one job it does well.
## The roster
Runs the whole pipeline and routes work to every specialist. The only agent you talk to directly.
A Socratic thinking partner that sharpens your raw idea into a testable concept.
A market and feasibility investigator that grounds every claim in a source you can click.
A requirements writer that works section by section, grounded in your research.
An optional system design specialist for the technical half of Define.
A UI/UX specialist for brand, user flows, and screen specifications.
A senior visual designer for tokens, components, and real HTML previews.
The implementation agent that writes your actual codebase inside a live sandbox.
A real-browser tester that verifies the app actually works, ending in a single verdict.
Owner of the publish pipeline, from sandbox to a live URL you own.
## Pipeline order
Agents map to the project stages you move through in Build:
| Stage | Agents |
| ----------------- | -------------------------------------------- |
| All stages | Orchestrator |
| Stage 1: Ideate | Ideation Agent |
| Stage 2: Discover | Research Agent |
| Stage 3: Define | PRD Agent, plus the optional Architect Agent |
| Stage 4: Design | Design Agent, Design System Agent |
| Stage 5: Develop | Fullstack Builder |
| On demand | QA Agent, Deploy Agent |
QA and Deploy are not stages. You run them as on-demand actions: QA whenever you want the app verified, Deploy whenever you want to ship.
## One shared context
The agents do not start from scratch at each stage. Every agent reads the artifacts the previous agents produced, and the Orchestrator maintains a project wiki and cross-agent memory so nothing agreed in one stage gets forgotten in the next.
Concretely, the chain of custody looks like this: the Ideation Agent logs assumptions and open questions; the Research Agent answers them with cited findings; the PRD Agent writes requirements against those artifacts rather than inventing them; the Design and Design System Agents design the product the PRD defines; the Fullstack Builder implements it on the exact design tokens the Design System Agent locked; the QA Agent tests the critical flows listed in the PRD.
You never address a specialist directly. The Orchestrator is the only agent that talks to you; it delegates every research question, PRD section, design decision, and line of code to the right specialist and proposes stage transitions for your approval.
## Model configurability
No agent is hardcoded to a specific model. The model each agent runs on is admin-configurable, and you can bring your own keys instead of using platform credits: Anthropic, OpenAI, or Google keys, or an OpenRouter gateway key. See [BYOK and models](/docs/platform/byok-and-models).
## Where to go next
Start with the [Orchestrator](/docs/agents/orchestrator) to understand how work gets routed, then follow the pipeline in order from [Ideation](/docs/agents/ideation) through [Deploy](/docs/agents/deploy). If you want the stage-by-stage product walkthrough instead of the agent-by-agent view, see the [Build surface overview](/docs/build/overview).
# PRD Agent
Source: https://productos.dev/docs/agents/prd
A requirements writer that turns your concept and research into a structured PRD, one section at a time behind an outline-approval gate.
The PRD Agent translates the concept and research into a structured product requirements document, one section at a time behind an outline-approval gate. Its system prompt draws the line clearly: "Every section you write must be grounded in the prior stages' artifacts, not invented from scratch."
Because it writes against the actual ideation and research artifacts, every requirement traces back to evidence. In revision mode it makes targeted edits instead of rewriting, so an approved spec stays approved.
## Templates
The agent works from four templates:
| Template | Sections |
| ---------------------- | -------- |
| ProductOS Standard | 10 |
| Amazon PRFAQ | 8 |
| Lean | 6 |
| Enterprise / Regulated | 12 |
## Tools
| Tool | What it does |
| ------------------- | --------------------------------------------------------------------- |
| `write_prd_section` | Writes one PRD section per call, the primary deliverable |
| `load_constraints` | Loads the project's locked constraints before writing |
| `ask_agent` | Consults the Research or Ideation Agent when a section needs evidence |
| `web_search` | Fills small factual gaps without leaving the document |
## What it reads and produces
**Reads:** the ideation brief; the research synthesis; a section spec from the approved outline.
**Produces:** PRD sections and an executive summary, in any of the four template formats.
## Where it sits in the pipeline
The PRD Agent owns Stage 3, Define. It consumes what the [Research Agent](/docs/agents/research) produced in Discover and turns it into the spec everything downstream is built from. The [Orchestrator](/docs/agents/orchestrator) scaffolds the outline first with `setup_prd_outline`, you approve it, and only then does the PRD Agent write sections one by one against that outline.
Within the same stage, the optional [Architect Agent](/docs/agents/architect) can take the finished PRD deeper on the technical side. Otherwise, the PRD flows straight into the [Design Agent](/docs/agents/design) in Stage 4.
## Working with it
The outline-approval gate is where you have the most leverage. Once the outline is approved, the agent fills in sections against it; changing your mind about structure after ten sections are written costs more than getting the outline right up front.
Spend your review effort on the outline. Cut sections you do not need, pick the template that matches your context (Lean for a quick MVP, Enterprise for regulated domains), and only then let the agent write. For later changes, ask for a targeted revision: revision mode edits the affected section instead of regenerating the document.
# QA Agent
Source: https://productos.dev/docs/agents/qa
A real-browser tester that drives headless Chromium against your app, checks flows, APIs, and accessibility, and returns one verdict.
The QA Agent drives a real headless Chromium browser against your app's preview URL, screenshotting after every action. Its system prompt states the job plainly: "Your job: verify whether the user's app actually works."
It covers four areas: critical user flows from the PRD, per-route visual checks, backend API checks, and accessibility plus console errors. Every run ends in a single verdict, pass, partial, or fail, with severity-ranked findings and suggested fixes. A fail can chain straight into an automated fix run by the Fullstack Builder, closing the loop without you triaging bug reports.
## Tools
| Tool | What it does |
| ------------------------------------------------------------ | --------------------------------------------------------- |
| `navigateTo` / `clickElement` / `typeText` / `assertVisible` | Drives the real browser through your app's critical flows |
| `takeScreenshot` / `observePage` | Captures visual evidence after every action |
| `listRoutes` / `callApi` / `assertApiResponse` | Exercises the backend API surface directly |
| `runAxeAudit` / `getConsoleErrors` / `getNetworkErrors` | Accessibility audit plus console and network error sweeps |
| `log_finding` / `write_qa_report` | Severity-ranked findings and the final verdict report |
## What it reads and produces
**Reads:** the live preview URL; critical flows from the PRD; the app's route map.
**Produces:** a verdict of pass, partial, or fail; severity-ranked findings with screenshots; suggested fixes, chainable into an auto-fix run.
## Where it sits in the pipeline
QA is an on-demand action, not a stage: you run it whenever you want the app verified, typically after the [Fullstack Builder](/docs/agents/fullstack-builder) has built or changed something significant. Because the critical flows it tests come from the PRD, it is checking the app against your spec, not against a generic checklist. A sensible rhythm is build, QA, fix, then hand off to the [Deploy Agent](/docs/agents/deploy) once you have a pass.
The browser is real: headless Chromium driven through Browserbase or Steel with Stagehand, and the accessibility audit is a real axe run, not a heuristic.
## Working with it
The verdict is designed to be actionable without triage. Findings arrive severity-ranked with screenshots of the exact moment something went wrong, and each includes a suggested fix.
Let a fail verdict do the work. Instead of reading the findings and describing the bugs back in chat, chain the fail into an auto-fix run: the findings flow to the Fullstack Builder as a targeted fix task, and you re-run QA afterward to confirm the verdict flipped. Your review effort is better spent on partial verdicts, where judgment calls about severity actually matter.
# Research Agent
Source: https://productos.dev/docs/agents/research
A market and feasibility investigator that researches competitors, market size, and validation across many sources, citing every claim.
The Research Agent runs structured, multi-source investigation across competitors, market size, user validation, and regulation. Its system prompt sets the standard: "You are an INVESTIGATOR grounding every claim in a source the user can click." No hand-waved market numbers; findings, sources, and competitors are logged as separate, auditable records.
It also treats your own customers as primary evidence. It pulls real workspace signals like calls, tickets, and reviews into the analysis, and when the evidence does not exist yet it can draft a validation survey, give you a share URL, and analyze the responses.
## Tools
| Tool | What it does |
| -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| `exa_search` / `exa_fetch` | Semantic web search with full-text extraction, from fast to deep |
| `search_reddit` / `search_reviews` / `search_app_stores` / `search_github` | Community discussion, G2 and Trustpilot reviews, iOS and Play store reviews, and GitHub signals |
| `generate_survey` / `analyze_survey_responses` | Drafts a validation survey with a share URL, then analyzes the responses |
| `write_research_run` | Writes the per-topic research document, the primary deliverable |
| `log_finding` / `log_source` / `log_competitor` | Batched, auditable records behind every claim |
## What it reads and produces
**Reads:** the ideation concept brief; a specific research task; workspace customer signals such as calls, tickets, and reviews.
**Produces:** sourced findings and a competitor registry; per-topic research documents; a rolling research brief and survey links.
## Where it sits in the pipeline
The Research Agent owns Stage 2, Discover. Its main input is what the [Ideation Agent](/docs/agents/ideation) left behind: the concept brief plus the logged assumptions and open questions, which become concrete research tasks. Its output is the evidence base the [PRD Agent](/docs/agents/prd) writes requirements against in Define, so every requirement in the spec traces back to something this agent found and cited.
## Working with it
Research runs are per-topic, so scoped questions get better results than broad ones. "Who are the top competitors for freelance invoicing tools and how do they price?" produces a tighter, better-sourced document than "research the market."
Check the sources, not just the summary. Every finding is logged with a clickable source, and the competitor registry is a separate auditable record. If a claim matters to your product decision, click through and read the original before you let it shape the PRD.
# Architecture (optional)
Source: https://productos.dev/docs/build/architecture
The optional technical deep-dive inside Define: eight architecture sections, decision records, and infrastructure cost estimates.
Architecture is an optional sub-phase inside the Define stage. Not every project needs it: a simple app can go straight from PRD to Design. Opt in when the technical shape of the system deserves real decisions, so the build that follows starts from decisions, not defaults.
## What it produces
* **Eight architecture sections**, real system design documents: system overview, container architecture, database design, API design, deployment architecture, security architecture, design patterns, and technical risks
* **Architecture decision records (ADRs)**, each captured with its context and consequences
* **Infrastructure cost estimates**, projecting the running cost of the proposed architecture
## Who runs it
The [Architect Agent](/docs/agents/architect), a system design and technical architecture specialist. One boundary matters: it designs the system; it does not write the app code. Implementation belongs to the [Fullstack Builder](/docs/agents/fullstack-builder) in the Develop stage.
Like the PRD, the architecture document is written behind an outline: the Orchestrator scaffolds the architecture outline, then delegates one section per call (`write_architecture_section`). Before writing, the agent loads your locked constraints, so the design respects tech-stack facts you have already fixed rather than reinventing them.
## What it reads
* The PRD sections from [Define](/docs/build/prd)
* Structured project constraints
* Locked tech-stack facts
## How you steer it
* **Lock your constraints first.** If you already know the stack, the hosting target, or a hard compliance requirement, get it into the project constraints before the sections are written; the agent reads them before every section.
* **Review the ADRs, not just the prose.** The decision records are where trade-offs live. Each one states the context and the consequences, which is exactly where to push back if a choice does not fit your situation.
* **Ask for the cost estimate early.** `estimate_infrastructure_cost` projects what the proposed architecture costs to run, and it is cheaper to change an architecture on paper than in production.
Skipping this sub-phase does not mean the build is unplanned; the Fullstack Builder still works from the PRD and the design system. It means the technical decisions are made during implementation instead of being documented ahead of it.
## What happens next
Architecture wraps up the Define stage. The Orchestrator proposes the transition to Design, where the [Design Agent](/docs/agents/design) and [Design System Agent](/docs/agents/design-system) turn the spec into flows, screens, and a token system, and the architecture documents remain in the project context for the Develop stage to build against.
Continue to [Design](/docs/build/design-stage).
# Deploy
Source: https://productos.dev/docs/build/deploy
How publishing works: preflight build, GitHub push, Vercel deployment, self-fixing broken builds, the deploy ledger, and custom domains.
Deploy is an on-demand action: whenever the project is ready, it takes the built app out of the sandbox and ships it to a live production URL, with the code in a GitHub repo you own.
## Who runs it
The [Deploy Agent](/docs/agents/deploy), the owner of the publish-and-deploy pipeline for your project. Its mandatory first move is `check_recent_deploy`: it checks the current deployment state before doing anything, so repeat requests do not stack duplicate deploys.
## The pipeline
The agent looks at the most recent deployment first. If a deploy is already live or in flight, it works from that state.
A production build runs inside the sandbox before anything ships. Broken builds are caught here, not on the hosting platform.
The codebase is pushed to GitHub. This is the same repo your code has been syncing to as it was written; the deploy just makes it current.
The agent creates or reuses the Vercel project, syncs environment variables, triggers the deployment, and polls it to completion.
## Self-fixing broken builds
When a build breaks, the agent does not just report the failure. It reads the Vercel build logs, diagnoses the error, and applies up to three targeted fix iterations before asking you for help. Most build breakages never reach you.
## The deploy ledger
Every release is accounted for. The agent keeps a cumulative deploy ledger for the project, so you can see what shipped and when, across every deploy, not just the latest one.
## URLs and custom domains
Your product ships to its own URL at `{slug}.product-os.app`. You can also point a custom domain at the deployment; see [Deployments and domains](/docs/platform/deployments-and-domains) for the platform-level details.
## What it reads
* The built project in your sandbox
* The project's environment variables
* The deployment target
## How you steer it
* **Ask for a deploy from the chat when you are ready.** Deploy is on demand; there is no stage gate to pass first.
* **Run [QA](/docs/build/qa) first.** The preflight build proves the app compiles; a QA pass proves it behaves. Together they make a deploy boring, which is the goal.
* **Let the fix iterations run.** If the build fails, the agent gets three targeted attempts with the real build logs before it comes back to you; when it does ask, it has already narrowed the problem.
There is no lock-in at the finish line: the deployed code lives in your GitHub repo, and the full project remains exportable. What ships is yours.
## After the deploy
The app is live. From here you can keep iterating in [Develop](/docs/build/develop-stage), retest with [QA](/docs/build/qa), and deploy again; the ledger keeps the history, and `check_recent_deploy` keeps repeat ships clean.
# Design
Source: https://productos.dev/docs/build/design-stage
How the Design stage sets up your brand, maps user flows, specs every screen, and locks a production-ready design system.
Design is the fourth stage of the Build pipeline. It turns the approved spec into the visual product: a brand direction, user flows, UI screen specifications, and a design system that every downstream build agent works from. Because it designs from your actual PRD, the screens are for the product you defined, not a generic template.
## What the stage produces
* A locked brand direction: palette, font pairing, vibe report, and a mood board of visual references
* User-flow diagrams
* UI screen specifications for the product's screens
* The design system: canonical design tokens, a component system, and `DESIGN.md`, the brief every build agent reads
* Real dark and light HTML previews of the design system, rendered before any product code exists
## Who runs it
Three agents share the stage:
* **The [Orchestrator](/docs/agents/orchestrator)** runs brand setup in automatic mode, generating the brand palette, font pairing, and vibe report for the project.
* **The [Design Agent](/docs/agents/design)** reads everything the earlier stages produced, the concept, the research, and the PRD, and turns it into user flows and screen specifications. It keeps your workspace in sync as it works, switching the active design tab as it moves through brand, flows, and screens.
* **The [Design System Agent](/docs/agents/design-system)** is a senior visual designer benchmarked against Linear, Vercel, Stripe, Notion, and Apple's Human Interface Guidelines. From the locked brand it builds the design tokens, the component system, and `DESIGN.md`, then renders dark and light previews so you can judge the system before a line of product code exists. Its own brief for taste: "Restraint over flourish. Personality you can name."
The [Fullstack Builder](/docs/agents/fullstack-builder) also appears in this stage under the Frontend Engineer label, running live Next.js builds in the Design Builder tab.
## What it reads
* The concept and research from earlier stages
* The PRD, including its personality notes
* The locked brand guidelines, any assets you upload, and the mood board
## How you steer it
* **Weigh in on the brand before the system is built.** The brand direction is the input everything else derives from; uploaded assets and mood-board feedback shape it directly.
* **Review the flows before the screens.** Flow diagrams are cheaper to change than a full set of screen specs.
* **Judge the previews.** The dark and light HTML previews exist precisely so you can react to the real system, spacing, type, and components, not a description of it. The brief can be edited surgically, so a correction does not mean starting over.
The design system's tokens are the source for every downstream build agent. This is why shipped ProductOS products look designed rather than generated: the Develop stage implements your screens on your tokens, not on defaults.
## What happens next
With flows, screen specs, and `DESIGN.md` locked, the Orchestrator proposes the transition to Develop. The [Fullstack Builder](/docs/agents/fullstack-builder) consumes the design tokens and the PRD and writes the actual codebase, screen for screen.
Continue to [Develop](/docs/build/develop-stage).
# Develop
Source: https://productos.dev/docs/build/develop-stage
How the Develop stage turns your spec and design system into a real codebase, built by a coding agent inside a live cloud sandbox.
Develop is the fifth stage of the Build pipeline: implementation. A real coding agent works headless inside your project's cloud sandbox, editing files and running commands directly against a pre-installed Next.js project, with a live preview you can watch as it builds.
## What the stage produces
* The application codebase, written in your project's sandbox
* A live dev preview URL that updates as the app is built
* Code that syncs to your own GitHub repo as it is written: full export, no lock-in
## Who runs it
The [Fullstack Builder](/docs/agents/fullstack-builder). It is not a code generator that returns a blob of files; it is a full coding agent with the complete sandbox toolset, reading, writing, and editing files and running shell commands, iterating the way an engineer does. In the Design stage the same agent appears as the Frontend Engineer; in Develop it builds the whole stack.
One rule shapes the whole system here: the Orchestrator is forbidden from writing code itself. As its prompt puts it, "Code belongs to the Develop sub-agent." Every implementation task is delegated to the builder.
Long-running build tasks execute as durable background jobs, broken into checkpointed steps, so a failure in one step retries that step rather than restarting the whole run.
## What it reads
* The design system tokens and `DESIGN.md` from the [Design stage](/docs/build/design-stage)
* The PRD from [Define](/docs/build/prd), plus architecture documents if you ran that sub-phase
* The concrete build task delegated by the Orchestrator
Because it consumes the locked tokens and the actual spec, the code implements the product you specified, screen for screen, on the design system your Design System Agent locked, not on framework defaults.
## The sandbox and live preview
Every project runs in an isolated cloud sandbox with a live preview URL. You watch the app take shape as the builder works, and the same preview URL is what the [QA Agent](/docs/agents/qa) later drives a real browser against.
## How you steer it
* **Delegate concrete tasks from the chat.** "Build the onboarding flow" lands better than "keep going"; the builder receives a specific task each run.
* **Use the live preview as your review surface.** React to the running app, not to code diffs, and feed corrections back through the Orchestrator as new build tasks.
* **Let QA close the loop on bugs.** Instead of hand-triaging what looks broken, run [QA](/docs/build/qa); a failed verdict can chain directly into a targeted auto-fix run by the builder (`delegate_to_develop_fix`).
The code is yours throughout. It syncs to your GitHub repo as it is written, so you can pull it into Cursor or any editor at any point; ProductOS project context is also available over MCP.
## What happens next
Develop is the last pipeline stage. From here, [QA](/docs/build/qa) and [Deploy](/docs/build/deploy) are on-demand actions: test whenever there is something to verify, ship whenever you are ready.
# Ideation
Source: https://productos.dev/docs/build/ideation
How the Ideation stage turns a raw idea into a sharp, testable product concept through Socratic questioning, not invention.
Ideation is the first stage of the Build pipeline. Its job is to turn a raw idea into a concept sharp enough to research and build, before any money or build time is spent.
## What the stage produces
* A concept brief that states the problem, the target user, and what must be true for the product to work
* A log of the assumptions the concept depends on
* A log of open questions for the Research Agent to answer in the next stage
## Who runs it
The [Ideation Agent](/docs/agents/ideation) is a Socratic thinking partner. Its own system prompt puts it plainly: "You are a QUESTIONER who draws the concept out of the user." It is explicitly not a writer that invents a concept for you. It asks, you answer, and the concept takes shape from your answers.
While you talk, it works with a small, focused toolset: it records unresolved questions (`log_open_question`) and assumptions (`log_assumption`), checks claims against the live web as they come up, consults a peer agent (typically Research) for a quick fact-check, and maintains the rolling concept brief as a markdown document.
## What it reads
* Your raw idea, in whatever shape you bring it
* Any prior concept brief, if you are revisiting an existing project
* The project wiki maintained by the Orchestrator
## How you steer it
Ideation is the most conversational stage, and the steering is the conversation itself. A few things that help:
* **Answer honestly, including "I don't know."** Unknowns are not failures here; they become logged open questions that Discover will investigate with real sources.
* **Push back on framings that feel wrong.** The brief is rolling, so corrections are folded in as you go rather than requiring a rewrite.
* **Name your assumptions when you notice them.** The agent logs assumptions it surfaces, but you can flag your own and they go into the same record.
The open-questions log is the handoff contract with the next stage. The more precisely a question is stated during Ideation, the more useful the sourced answer from Research will be.
## What happens next
When the concept is sharp, the [Orchestrator](/docs/agents/orchestrator) proposes the transition to the Discover stage for your approval. The [Research Agent](/docs/agents/research) then picks up the concept brief and the open-questions log as its starting inputs, and grounds each question in sources you can click.
Continue to [Research](/docs/build/research).
# Build overview
Source: https://productos.dev/docs/build/overview
How the Build surface runs the full product pipeline, from raw idea to deployed app, with one shared project context across every stage.
Build ([beta.productos.dev](https://beta.productos.dev)) is the flagship ProductOS surface: the full idea-to-deploy pipeline. You describe your product once, and a team of specialized AI agents researches it, writes the PRD, designs it, codes it, and ships it, all sharing one project context. Nothing agreed in one stage gets forgotten in the next.
## How it works
You talk to one agent: the [Orchestrator](/docs/agents/orchestrator). It never does the domain work itself; every research question, PRD section, design decision, and line of code is routed to the right specialist. It maintains a project wiki, keeps a rolling progress ledger, and proposes stage transitions for your approval, so the project only advances when you say so.
Each stage's output becomes the next stage's input. The PRD is written against your actual research; the screens are designed against your actual PRD; the code implements your actual screens on your locked design tokens.
## The stage map
| Stage | What it produces | Agent |
| --------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| 1. Ideate | Concept brief: problem, target user, assumptions, open questions | [Ideation Agent](/docs/agents/ideation) |
| 2. Discover | Sourced findings, competitor registry, research documents | [Research Agent](/docs/agents/research) |
| 3. Define | The PRD, section by section behind an outline-approval gate | [PRD Agent](/docs/agents/prd) |
| 3b. Architecture (optional) | Architecture sections, ADRs, infrastructure cost estimates | [Architect Agent](/docs/agents/architect) |
| 4. Design | Brand, user flows, screen specs, the design system | [Design Agent](/docs/agents/design), [Design System Agent](/docs/agents/design-system) |
| 5. Develop | The application codebase, with a live preview in the sandbox | [Fullstack Builder](/docs/agents/fullstack-builder) |
QA and Deploy are not stages; they are on-demand actions you can trigger whenever there is something to test or ship. The [QA Agent](/docs/agents/qa) drives a real browser against your app and returns a verdict; the [Deploy Agent](/docs/agents/deploy) takes the project from the sandbox to a live URL.
Stage transitions are proposed, not automatic. When a stage's work is done, the Orchestrator proposes the move; you confirm it. Telling it to move on is consent to advance.
## Where the work lives
Projects run in isolated cloud sandboxes with live preview URLs, so you can see the app as it is built. Generated code syncs to your own GitHub repo as it is written: full export, no lock-in. Your project context (PRD, research, designs) is also available in Cursor and Claude over MCP.
## Build vs Code vs Design
One account, credits shared across all three surfaces. Pick the one that matches how much of the pipeline you need.
The full pipeline. Use it when you want research, a PRD, designs, and a shipped product from one idea, with the whole trail documented.
The AI app builder with a live sandbox. Use it when you already know what to build and want to go straight to working code.
UI generation and templates. Use it when you need screens, brand systems, or design assets without the rest of the pipeline.
Meet the full roster: what each agent reads, produces, and how to steer it.
## Start here
Each stage has its own page covering what it produces, which agent runs it, what context it reads, and how you steer it: [Ideation](/docs/build/ideation), [Research](/docs/build/research), [PRD](/docs/build/prd), [Architecture](/docs/build/architecture), [Design](/docs/build/design-stage), [Develop](/docs/build/develop-stage), then [QA](/docs/build/qa) and [Deploy](/docs/build/deploy) on demand.
# PRD (Define)
Source: https://productos.dev/docs/build/prd
How the Define stage writes your product requirements document section by section, behind an outline-approval gate, in four templates.
Define is the third stage of the Build pipeline. It translates the concept and the research into a structured product requirements document: the spec that Design and Develop will execute against.
## What the stage produces
* The PRD itself, written one section at a time, plus an executive summary
* In revision mode, targeted edits to an already-approved document
## Who runs it
The [PRD Agent](/docs/agents/prd). Its defining rule, from its own system prompt: "Every section you write must be grounded in the prior stages' artifacts, not invented from scratch." Because it writes against the actual ideation and research records, every requirement traces back to evidence. When a section needs a fact it does not have, it consults the Research or Ideation Agent directly, or fills small factual gaps with a web search, rather than guessing.
## The outline-approval gate
The document is not generated in one shot. The flow is:
The Orchestrator scaffolds a PRD outline from your chosen template and the project context.
The outline is the contract for the document. Nothing gets written until the structure is right, so reshaping the doc costs a conversation, not a rewrite.
The PRD Agent writes one section per delegation, loading the project's locked constraints before writing each one.
## The four templates
| Template | Sections | Best for |
| ---------------------- | -------- | ----------------------------------------------------- |
| ProductOS Standard | 10 | Most products; the default, full-coverage spec |
| Amazon PRFAQ | 8 | Working backwards from the press release and FAQ |
| Lean | 6 | Early-stage concepts where speed beats coverage |
| Enterprise / Regulated | 12 | Products with compliance, audit, or procurement needs |
## What it reads
* The ideation concept brief
* The research synthesis from [Discover](/docs/build/research)
* The section spec from your approved outline
* The project's locked constraints
## How you steer it
* **Spend your attention on the outline.** It is the highest-leverage review point; approving a good outline is most of the work of getting a good PRD.
* **Challenge sections against the evidence.** Every claim should trace to an ideation or research artifact; if one does not, say so and the section gets rewritten against the record.
* **Use revision mode for changes.** After approval, the agent makes targeted edits instead of regenerating, so an approved spec stays approved and your review effort is not thrown away.
If your product has real technical complexity, run the optional [Architecture](/docs/build/architecture) sub-phase inside Define before moving on. The Architect Agent turns the PRD into system design documents and ADRs.
## What happens next
With the PRD approved (and architecture documented, if you opted in), the Orchestrator proposes the transition to Design. The [Design Agent](/docs/agents/design) reads the concept, the research, and the PRD, and designs the product you actually defined.
Continue to [Architecture](/docs/build/architecture) or skip ahead to [Design](/docs/build/design-stage).
# QA
Source: https://productos.dev/docs/build/qa
How QA runs a real browser against your app, what it tests, how verdicts work, and how a fail chains into an automatic fix run.
QA is an on-demand action, not a pipeline stage. Run it whenever there is something worth verifying: after a build task, before a deploy, or any time the app feels off. Its job, in the agent's own words: "verify whether the user's app actually works."
## Who runs it
The [QA Agent](/docs/agents/qa). It is not a linter or a static analyzer; it drives a real headless Chromium browser (via Browserbase/Steel with Stagehand) against your app's live preview URL, clicking, typing, and asserting like a user would, and it screenshots after every action so each finding comes with visual evidence.
## What it tests
Every run covers four areas:
| Area | What happens |
| ------------------------ | ----------------------------------------------------------------------------- |
| Critical user flows | The flows from your PRD, driven end to end in the real browser |
| Per-route visual checks | Each route loaded and visually checked, with screenshots |
| Backend API checks | The API surface exercised directly: routes listed, called, responses asserted |
| Accessibility and errors | An axe accessibility audit plus console and network error sweeps |
## What it reads
* The live preview URL from your sandbox
* The critical flows defined in your PRD
* The app's route map
Because the flows come from your PRD, QA tests the product you specified, not a generic checklist.
## Verdicts
Every run ends in a single verdict:
* **Pass**: the app works
* **Partial**: it works with problems worth fixing
* **Fail**: something critical is broken
The verdict comes with a report of severity-ranked findings, each backed by screenshots, plus suggested fixes.
## Auto-fix chaining
A fail does not have to land on your desk as a bug list. The findings can chain straight into an automated fix run: the [Fullstack Builder](/docs/agents/fullstack-builder) receives a targeted fix task generated from the QA report (`delegate_to_develop_fix`), applies the fixes in the sandbox, and you can run QA again to confirm. The loop is test, fix, retest, without you triaging bug reports in between.
## How you steer it
* **Run it from the chat whenever you want.** QA is on demand; you do not have to wait for a stage boundary.
* **Keep the PRD's critical flows honest.** They are what QA drives, so if a flow matters, make sure it is in the spec.
* **Decide what a partial means for you.** Severity-ranked findings let you choose between chaining an auto-fix, cherry-picking what matters, or shipping anyway.
A QA pass immediately before deploying is cheap insurance: the [Deploy Agent](/docs/agents/deploy) verifies that the build compiles, but QA is what verifies that the product behaves.
## What happens next
When the verdict is good enough, ship it. Continue to [Deploy](/docs/build/deploy).
# Research (Discover)
Source: https://productos.dev/docs/build/research
How the Discover stage investigates competitors, market size, and user validation, grounding every claim in a source you can click.
Discover is the second stage of the Build pipeline. It replaces assumptions with evidence: structured, multi-source investigation across competitors, market size, user validation, and regulation, with every claim grounded in a clickable source.
## What the stage produces
* **Findings, sources, and competitors** logged as separate, auditable records, so every claim can be traced back to where it came from
* **Per-topic research documents**, the primary deliverable of each research run
* **A rolling research brief** that synthesizes the runs
* **Surveys**, when the evidence you need does not exist yet: the agent drafts a validation survey with a share URL, then analyzes the responses
## Who runs it
The [Research Agent](/docs/agents/research) is an investigator, not a summarizer. From its system prompt: "You are an INVESTIGATOR grounding every claim in a source the user can click." No hand-waved market numbers.
## Sources
The agent works across several kinds of evidence:
| Source | What it provides |
| ------------------------------------------- | ---------------------------------------------------------------- |
| Exa web search (`exa_search` / `exa_fetch`) | Semantic web search with full-text extraction, from fast to deep |
| Reddit | Community discussions and sentiment |
| G2 and Trustpilot reviews | What users say about competing products |
| App stores | iOS and Play review signals |
| GitHub | Open-source landscape and developer signals |
| Surveys | Fresh validation data when no source has the answer |
Under the hood, the research system cross-validates findings across sources: results that multiple independent sources confirm are treated as stronger signals than single-source claims.
## Customer signals
Your own customers count as primary evidence. The agent can pull real workspace signals, calls, tickets, and reviews, into the analysis alongside external research, so validation is not limited to what strangers on the internet say.
## What it reads
* The concept brief and open-questions log from [Ideation](/docs/build/ideation)
* The specific research task the Orchestrator delegates
* Workspace customer signals, when available
## How you steer it
* **Delegate specific questions from the chat.** The open questions logged in Ideation are the natural backlog; you can also ask for a targeted run on anything ("who are the top three competitors and how do they price?").
* **Ask for depth where it matters.** A pricing landscape and a regulatory review are different jobs; scope each run to one topic and the per-topic documents stay useful.
* **Use surveys for the gaps.** When no source can answer a question about your users, ask for a survey; you get a share URL, and the responses feed back into the analysis.
Because findings, sources, and competitors are logged as individual records rather than buried in prose, you can audit any claim later, including from the PRD stage, where every requirement must trace back to evidence.
## What happens next
When the open questions have sourced answers, the Orchestrator proposes the transition to Define. The [PRD Agent](/docs/agents/prd) writes the requirements document directly against the research synthesis, so the spec inherits the evidence.
Continue to [PRD](/docs/build/prd).
# GitHub sync
Source: https://productos.dev/docs/code/github-sync
Your generated code lives in Git from the first turn. Connect your own GitHub account to push, pull, and import repositories. No lock-in.
Code you build on the Code surface is never trapped in the platform. Generated code is pushed to a Git repository as it is written, turn by turn, and you can sync everything to a repository you own at any time.
## Two repositories, one project
Every project involves up to two GitHub locations, and it helps to know which is which:
* **The platform-hosted repository**: every project gets one automatically. This is the canonical store for your project's files; the agent pushes to it on every turn. You will see it as a repository chip on the project. It exists whether or not you have connected a GitHub account.
* **Your personal GitHub**: your own account, connected under Settings, then Connections. This is what you use to export code to a repository you own, pull from your existing repositories, or import a project.
A project always having a platform repository while Connections shows "not connected" is normal: the platform repo is automatic, the personal connection is opt-in.
## Push to your own repository
With your personal GitHub connected, use Push to GitHub from the project. You can either:
* **Create a new repo**: give it a name and the project's code is pushed to a fresh repository under your account.
* **Push to an existing repo**: point at a repository you already own.
## Pull from GitHub
Pull from GitHub brings changes from a repository into your project's sandbox. Pick the repository and optionally a branch; the dialog reports how many files were pulled. This is also how mobile projects hot-reload agent fixes into the live preview. See [Mobile](/docs/code/mobile).
## Import an existing project
You can start a Code project from an existing repository with Import from GitHub. Browse your personal repositories and organizations (with search and branch selection), or paste a repository URL directly. The imported code lands in a fresh sandbox with a live preview, and from there it behaves like any other project.
## Save and restore
The project toolbar has a Save button that commits your current state with a real commit message. Restore lets you roll the project back to any previously saved commit. Because Git is the canonical store, restoring is a first-class operation, not a best-effort undo.
## No lock-in
* Code syncs out continuously; there is no separate "export" step to unlock it.
* You can disconnect your personal GitHub at any time from Settings, then Connections.
* Full export of every project is always available. See [Code ownership](/docs/platform/code-ownership).
# Mobile apps
Source: https://productos.dev/docs/code/mobile
Build native mobile apps on the Code surface with Expo and React Native: device-frame previews, on-demand databases, and an App Store publish wizard.
The Code surface builds native mobile apps as Expo / React Native projects. Create a project with the mobile type and the same chat-driven workflow applies: describe the app, and the coding agent builds it in a dedicated mobile build environment while you watch a live preview in a device frame.
## The mobile preview
* **Device frames**: the preview renders inside a device frame. A device picker, curated by form factor, lets you switch between phones and tablets, and the frame feeds real device safe-area insets into the preview so it matches on-device chrome. Apps render edge to edge.
* **Stable preview URL**: the preview is pinned to a stable URL that survives sandbox restarts, so the address does not change under you between sessions.
* **Branded loading**: your app shows a real splash screen with its own name and icon while loading, and that branding is committed to the project's repository so it persists across rebuilds.
* **Build feedback**: the preview auto-refreshes when a mobile build completes, with a chime so you notice.
When the agent pushes a fix to the project's repository, use Pull from GitHub to bring it into the running preview; the app hot-reloads with the change.
Mobile projects always run in the dedicated mobile environment. If a project ever resumes onto the wrong environment type, it is detected and recreated automatically, so a mobile project never boots as a web project.
## Databases and storage
Mobile projects get the same on-demand infrastructure as web projects: when your app needs a database, a per-project serverless Postgres database is provisioned and wired into the environment. App file uploads go to private storage and are served through a proxy rather than public URLs.
## Publishing to the App Store
The mobile publish wizard prepares a complete store listing from your actual app, not from generic boilerplate.
### Store metadata
* Listing copy is generated in two stages, first a brief and then the copy, grounded in the real app you built.
* Your app's existing icon is sourced from its repository automatically.
* Generated metadata and assets are persisted per project, so they do not regenerate every time you reload the wizard.
* If the wizard does not have enough context about the app, it shows a single "What is this app?" field to fill the gap.
### Screenshot Mode
Screenshot Mode captures store screenshots directly from your app's live preview:
* Capture any screen; screenshots are named automatically after the app screen they show.
* Each capture comes in two variants: a clean screenshot with no device chrome, and a framed variant cropped to the device.
* Screenshots are grouped by device class (iPhone and iPad, or Phone and Tablet), and tablet captures use their own store dimensions.
* The generated pack includes per-screen captions written from the actual image content, styled with your app's real brand colors.
Generating the full screenshot pack takes around 3 to 5 minutes; the wizard sets that expectation while it works.
# Code surface overview
Source: https://productos.dev/docs/code/overview
The Code surface at develop.productos.dev is an AI app builder: describe what you want in chat and a coding agent builds it in a live cloud sandbox.
The Code surface, at [develop.productos.dev](https://develop.productos.dev), is the ProductOS AI app builder. You describe what you want in chat; a real coding agent works headlessly inside your project's sandbox, writing files, installing dependencies, and running the dev server while you watch the result in a live preview. It shares your ProductOS account and credits with the Build and Design surfaces.
## What you can build
| Project type | Stack | Notes |
| ------------ | ------------------- | ------------------------------------------------------------------- |
| Web app | Next.js | Full-stack apps with a database provisioned on demand |
| Website | Astro | Marketing and content sites |
| Mobile app | Expo / React Native | Native apps with a device-frame preview; see [Mobile](/docs/code/mobile) |
You can start from a blank prompt, from a [template](/docs/code/templates), or by importing an existing GitHub repository.
## The workspace
A project opens on the live preview, with chat on the left and the preview taking most of the screen. From there:
* **Preview** shows your running app at a live URL, backed by an isolated cloud [sandbox](/docs/code/sandboxes). A toolbar button opens it in a new tab.
* **Code view** gives you the full file tree with an always-open file search, so you can read exactly what the agent wrote.
* **Storage** shows files your app stores through its per-project file storage.
Each project keeps its work in named sessions. You can rename sessions inline and switch between them from a dropdown in the project view.
## Build mode and Plan mode
The composer has a Build/Plan toggle, shared between the home screen and project chat:
* **Build** sends your request straight to the coding agent.
* **Plan** has the agent lay out an approach first, so you can review the plan before code changes happen. Plan mode is marked with an orange accent so you always know which mode you are in.
The agent follows a task-completion protocol: it works through a multi-step plan to the end without needing a nudge between steps.
## Pointing at things
Instead of describing a UI element in words, use the Select tool on the preview. Click any element and it appears in chat as a card showing the source file and line it came from, so your next instruction targets exactly that element. When you select an image, an Update Image button lets you swap it directly.
You can also attach files to a message. All file types are accepted, including text files, code files, and zip archives, and they reach the agent as context.
## Databases, storage, and secrets
* **Database**: when your app needs one, the agent provisions a per-project serverless Postgres database on demand and wires the connection string into the sandbox environment. This works the same for web and mobile projects.
* **File storage**: built apps can provision their own file storage for uploads and assets, visible in the project's Storage tab.
* **Secrets**: when the agent needs an API key or other secret from you, it asks through a secrets request in chat rather than having you paste values into code.
## When something breaks
Built apps detect their own runtime errors and report them back to the builder, so the agent can see what went wrong in the running app, not just in the build log. Deployment failures feed back too: the agent reads the complete build log and re-drives itself to fix the problem.
## Your code stays yours
Generated code is pushed to a Git repository as it is written, and you can sync it to your own GitHub account or export everything at any time. See [GitHub sync](/docs/code/github-sync) and [Code ownership](/docs/platform/code-ownership).
## Next steps
How the isolated cloud environments behind every project work.
Clone a curated starter into a fresh project in seconds.
Push to your own repo, pull changes, or import an existing project.
Ship your project to a live URL, with custom domains on Pro.
# Publish
Source: https://productos.dev/docs/code/publish
Ship a Code project to production in one flow, watch the deployment, and connect a custom domain on production-capable paid plans.
Publishing takes the project in your sandbox and deploys it to a real, public URL. It is a single flow from the project view: open Publish, pick a subdomain, and watch the deployment go live.
## Publishing a project
From your project, open Publish. Publishing always deploys the project's currently selected branch.
Pick the subdomain your app will live on. Your app is served at `https://.product-os.app`. If the subdomain is already taken you get a clear conflict error; pick another.
The dialog shows publishing progress and flips to a deployed view when the app is live, with your live URLs ready to open or copy.
You can change the subdomain later from the same dialog; the deployed view includes a subdomain editor along with your domains and analytics for the published site.
Projects created from templates or GitHub imports publish the same way as projects built from scratch.
If a project was published from another ProductOS surface, the Publish dialog shows its published state and live URLs instead of asking you to deploy again.
## Custom domains
Custom domains and production web deployment are available on Builder, Founder, team, and agency plans. Hobby provides a ProductOS-branded draft preview rather than a production deployment. See [Products, channels and billing](/docs/pricing/products-channels-and-billing).
To connect your own domain:
1. Deploy the project first, then add your domain in the Publish dialog.
2. The dialog shows the exact DNS records to create at your DNS provider:
* **Apex domains** (like `example.com`) need an A record, since a CNAME is not valid at the zone apex.
* **Subdomains** (like `app.example.com`) use a standard CNAME record pointing to `cname.vercel-dns.com`.
* Some domains also require a TXT record for verification; when needed, it appears in the same table.
3. ProductOS keeps checking your domain until every record is verified and the domain is actually serving traffic, so you can watch it go live from the dialog.
You can attach more than one custom domain. One of them is the primary domain, which is the URL used for share links; the platform subdomain keeps working alongside it. Domains can be removed from the same dialog at any time.
## When a deploy fails
Deploy failures are not a dead end. The build log is captured in full and fed back to the coding agent, which can automatically re-drive itself to fix the failure and deploy again.
# Sandboxes
Source: https://productos.dev/docs/code/sandboxes
Every Code project runs in its own isolated cloud sandbox with a live preview URL. Learn the lifecycle, cold boot behavior, and capacity limits.
Every project on the Code surface runs in its own isolated cloud sandbox: a disposable environment with a file system, a terminal, and a running dev server. The coding agent works inside the sandbox, and you watch the result through a live preview URL embedded in the workspace. Nothing runs on your machine, and AI-generated code never touches the ProductOS host environment.
## One sandbox per project
Sandboxes are project-scoped. Opening a project either reconnects to its existing sandbox or provisions a fresh one. The lifecycle looks like this:
1. **Create**: a sandbox is provisioned when the project needs one.
2. **Execute**: the agent writes files, installs dependencies, and runs build commands.
3. **Preview**: a live URL is returned and embedded in the workspace, with an option to open it in a new tab.
4. **Teardown**: after a period of inactivity, the sandbox is cleaned up. Your code is safe; it lives in the project's Git repository, not only in the sandbox.
Mobile projects use a dedicated mobile build environment rather than the web one. If a mobile project ever resumes onto the wrong environment type, it is detected and recreated automatically. See [Mobile](/docs/code/mobile).
## Cold boots
When you return to a project whose sandbox has been torn down, ProductOS restores it: it pulls your code back in, reinstalls anything missing, and restarts the dev server. A boot loader shows progress while this happens.
A few things keep cold boots short:
* **Prewarming**: after your code is pulled in, the home route is compiled ahead of time, so you do not pay a cold compile on your first navigation.
* **Volume-backed templates**: curated templates that ship with a prepared volume boot in about 3 seconds instead of roughly 25 seconds for the standard import path. See [Templates](/docs/code/templates).
* **A hard ceiling on the loader**: if the preview cannot be restored within the time limit (150 seconds by default), you get an actionable error with options to try again or start a build, instead of an indefinite spinner.
The preview loader is dismissed when the app actually responds, not on a fixed timer. If you see the loader for a while on a large project, the sandbox is still compiling; it will hand off as soon as the app serves a real page.
## Capacity and plan limits
Plans govern active products, concurrent agents, and included AI capacity. ProductOS manages sandbox resources for the workload rather than selling RAM as a customer-facing pricing tier. AI usage is recorded in the workspace credit ledger and can be governed through plan and administrator limits. See [Pricing overview](/docs/pricing/overview) and [AI credits and models](/docs/pricing/ai-credits-and-models).
## Security notes
* Sandboxes are isolated from each other and from ProductOS infrastructure.
* Platform credentials never enter your sandbox. For example, when a template is cloned for you, the download happens server-side and only the extracted files reach the sandbox.
* Your project's canonical code lives in Git, so a torn-down sandbox never means lost work.
# Templates
Source: https://productos.dev/docs/code/templates
Clone a curated starter into a fresh private project on the Code surface. Volume-backed templates boot in about 3 seconds with a live preview.
The Code surface has a template gallery of curated, real applications you can clone into your own project. A template is not a mockup: it is a working codebase that boots in a sandbox with a live preview, and once cloned it is entirely yours to edit, sync to GitHub, and publish.
## Curated templates
The gallery lists templates that are verified to clone and boot end to end:
| Template | What it is | Stack |
| ----------- | -------------------------- | ------- |
| SOLEN | Architecture studio site | Astro |
| Echo | Content repurposing studio | Next.js |
| StudioFlow | CRM for photographers | Next.js |
| Lumen Notes | AI clinical documentation | Next.js |
| Orbit | Hybrid-casual web game | Next.js |
The [templates directory on the website](https://productos.dev/templates) lists 14 templates across the platform; the gallery on the Code surface is the curated, one-click-cloneable subset.
Some gallery entries are showcase-only: customer-built projects shown as proof of what the platform can do. Those link to the live site and cannot be cloned.
## Using a template
Open the template gallery on the Code surface and choose a template.
Using a template requires an account. If you are signed out, you are sent to sign-in and returned to the template flow afterward.
ProductOS creates a fresh, private project in your workspace and clones the template's source into it. The clone happens server-side with platform credentials, so you do not need to connect a GitHub account for this.
The template's code lands in a new sandbox and the dev server starts. You get a live preview URL and can immediately start editing through chat.
## Boot speed: the volume fast path
Templates load into the sandbox one of two ways:
* **Volume-backed** (the fast path): curated templates with a prepared volume mount their content directly into the sandbox and boot in about 3 seconds.
* **Standard import**: templates without a volume are downloaded and extracted into the sandbox, which takes roughly 25 seconds.
Either way you end up with the same thing: the full source in your own private project. The fast path only changes how quickly the first preview appears.
## After you clone
A cloned template behaves like any other Code project:
* Edit it through chat with the coding agent, or point at elements with the Select tool.
* Sync the code to your own GitHub repository. See [GitHub sync](/docs/code/github-sync).
* Publish it to a live URL. Projects created from templates can be published like any other project. See [Publish](/docs/code/publish).
# Brand and design systems
Source: https://productos.dev/docs/design/brand-and-design-systems
Create a design system from a prompt, your brand assets, or an existing website: tokens, a DESIGN.md spec, and dark and light HTML previews.
A design system on ProductOS is a complete, machine-readable definition of how your product should look. Agents consume it when they generate UI, so the look you define here carries through everything you build.
## What a design system contains
* **Color tokens**: a full semantic palette (primary, secondary, accent, background, foreground, muted, card, border, destructive, and more), each with its foreground pairing.
* **Typography**: sans and mono font families, a size scale, font weights, and line heights.
* **Spacing, radius, and shadows**: a spacing scale, border radius steps, and a shadow scale.
* **Atmosphere**: the personality layer, including the overall vibe (minimal, bold, playful, corporate, dark, or your own), section padding, card style, and animation style (subtle, energetic, or none).
* **DESIGN.md**: a written specification of the whole system that agents read when building UI.
* **Dark and light previews**: two self-contained HTML preview pages, one per theme, so you can judge the system as rendered UI rather than as a list of hex codes.
## Creating a design system from a prompt
Give it a name, for example "Neon Fintech" or "Brutalist Portfolio".
Write a short description of the look you want. Include colors, mood, industry, typography style, or reference brands for best results, for example: "A premium fintech design system with deep navy backgrounds, gold accents, sharp typography."
ProductOS generates the DESIGN.md first, then the tokens, then a dark-mode HTML preview, then converts it into the light-mode version.
After the first generation you stay in a refine flow, so you can keep iterating on the same system in follow-up prompts.
You can mark one design system as your default. Each system renders as a card whose preview reflects the actual system: its real colors and whether it is a dark or light theme.
## Bringing your own brand
Two ways to ground a design system in a brand that already exists:
* **Upload brand assets**: attach logos, hero images, product shots, and icons; each asset is labeled with its role so generation uses it correctly. You can also upload a PDF (for example, existing brand guidelines); its text is extracted and fed to the generator along with the document itself.
* **Import from a URL**: point at an existing website. ProductOS scrapes the site, extracts its color tokens, and generates a DESIGN.md and design system from what it finds. If a site blocks scraping or times out, you get a clear error rather than a half-imported system.
## Where design systems are used
Design systems apply to projects across the Design and Code surfaces, so generated UI lands already on-brand. On the Build surface, the [Design System Agent](/docs/agents/design-system) produces the same artifacts (tokens, DESIGN.md, dark and light previews) as a stage of the full pipeline; the format is shared.
# Design surface overview
Source: https://productos.dev/docs/design/overview
The Design surface at design.productos.dev generates UI: full design systems from a text prompt, a remixable template gallery, and brand import.
The Design surface, at [design.productos.dev](https://design.productos.dev), is the ProductOS home for UI generation. It extends the Code surface with design-specific capabilities: generating complete design systems from a description, a template gallery you can remix, brand import from an existing website, and Figma integration. It shares your ProductOS account and credits with the Build and Code surfaces.
## What you can do here
Describe a look in a sentence or two and get a full design system: tokens, a DESIGN.md spec, and dark plus light previews.
Browse the gallery by category, preview any template live, and remix it into your own project.
Point at an existing website and the surface extracts its colors and generates a design system from it.
Design projects run in the same live sandboxes as Code projects, so a generated design is a working site, not a static image.
## Real, running designs
Generated designs are working code in an isolated cloud sandbox with a live preview, the same infrastructure the Code surface uses. That means every design you generate can be inspected, iterated on in chat, screenshotted, and taken all the way to a deployed site. See [Sandboxes](/docs/code/sandboxes).
Beyond the core flow, the surface includes a visual design editor with AI-assisted component generation, Figma import and export integration, and 3D website generation built on Three.js and React Three Fiber.
## Design systems everywhere
A design system created here is not decoration; it is a set of machine-readable artifacts (design tokens, a DESIGN.md specification, and HTML previews) that agents across ProductOS consume when they build UI. The Design System Agent on the Build surface produces the same artifacts as part of the full pipeline. See the [Design System Agent](/docs/agents/design-system).
## Where to start
1. Open [design.productos.dev](https://design.productos.dev). You can browse templates without an account; generating and remixing require sign-in, and the free tier needs no credit card.
2. Either describe a design system you want, import a brand from a URL, or remix a template.
3. Iterate in chat, then take the result to GitHub or a live URL like any other ProductOS project.
# Design templates
Source: https://productos.dev/docs/design/templates
Browse the Design surface template gallery by category, preview any template live, and remix it into a project of your own in one click.
The Design surface has a template gallery of generated designs you can preview live and remix into your own projects. The gallery is public: you can browse it signed out, and sign in when you want to remix something.
## Browsing the gallery
Templates are organized by category: SaaS starters, landing pages, dashboards, e-commerce, blogs, UI components, animations, and styles, plus an "All templates" view that shows everything at once. Each template card shows its name, description, and tags, and reflects the template's actual look.
## Preview and remix
Every template supports two actions:
* **Preview**: boots the template so you can see it running live before committing to anything.
* **Remix**: clones the template into a project of your own. From there it behaves like any other ProductOS project: iterate on it in chat, apply your own [design system](/docs/design/brand-and-design-systems), sync it to GitHub, or publish it.
Some templates are paid. Paid templates show their price on the card; buying one unlocks Remix, and templates you have already purchased remix immediately.
## Showcase entries
A few gallery entries are showcase-only: proprietary, customer-built projects displayed as proof of what the platform produces. These have a "View live" action that opens the deployed site instead of a Remix action, and they cannot be cloned.
## Related galleries
* The [Code surface template gallery](/docs/code/templates) holds curated full-application starters (working codebases like SOLEN and Echo) that clone into a private project with a live sandbox.
* The [templates directory on the website](https://productos.dev/templates) lists templates across the whole platform.
# Core concepts
Source: https://productos.dev/docs/getting-started/core-concepts
The three ideas behind ProductOS: one shared project context, a staged pipeline, and specialized agents coordinated by an Orchestrator.
ProductOS rests on three ideas. Understand them and everything else in these docs falls into place.
## Shared context
Every project has one context that all agents read from and write to. Your idea, the ideation transcript, research findings, the PRD, architecture decisions, and design specs accumulate in one place instead of being scattered across tools.
This is the difference between ProductOS and a collection of point tools. When the PRD Agent writes a requirements section, it cites the Research Agent's findings. When the Fullstack Builder writes code, it builds against the Design Agent's screen specs. You never paste context from one stage into the next; the pipeline carries it.
The shared context is also portable: it is available in Cursor and Claude over [MCP](/docs/integrations/mcp), so external tools can build against the same PRD, research, and designs.
## The pipeline
Product work moves through five stages, in order:
```
Ideation -> Research (Discover) -> PRD / Define -> Design -> Develop
```
| Stage | What happens |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Ideation** | The idea is sharpened; assumptions and open questions are logged |
| **Research** | Multi-source, cited research into the market, competitors, and users |
| **PRD / Define** | A structured PRD, written section by section behind an outline-approval gate. Optionally includes an Architecture pass |
| **Design** | User flows, screen specs, design tokens, and HTML previews |
| **Develop** | A real coding agent builds the app in an isolated sandbox with live preview |
Two things you might expect to be stages are not:
**QA and Deploy are on-demand actions, not stages.** You can run QA or deploy at any point, as many times as you like, without moving the project through a stage gate.
Stage transitions are proposed by the Orchestrator and approved by you. The pipeline gives you leverage without taking away control: nothing advances until you say so.
## Agents vs stages
Agents and stages are related but not the same thing:
* A **stage** is a phase of the project with a defined output (research findings, a PRD, screen specs, working code).
* An **agent** is a specialist that does work, usually within one stage.
The **Orchestrator** sits above both. It routes all work, is the only agent that talks to you, and proposes stage transitions. Every other agent is a specialist it delegates to: the Ideation Agent in Ideation, the Research Agent in Research, the PRD and Architect Agents in Define, the Design and Design System Agents in Design, and the Fullstack Builder in Develop (labeled "Frontend Engineer" when it works in the Design stage).
The QA Agent and Deploy Agent map to the on-demand actions rather than stages: they can be invoked whenever there is something to test or ship.
See the [agents overview](/docs/agents/overview) for the full roster and what each specialist does.
## How this plays out
A typical loop looks like this: you talk to the Orchestrator, it delegates to a specialist, the specialist writes its output into the shared context, and the Orchestrator proposes moving to the next stage. You approve, and the next specialist picks up everything produced so far. The result is a product built by a team that never loses the thread.
# Projects and stages
Source: https://productos.dev/docs/getting-started/projects-and-stages
How a ProductOS project moves through the five-stage pipeline, what each stage produces, and how sandboxes and templates fit in.
A project is the unit of work in ProductOS. It holds the shared context (idea, research, PRD, designs, code) and moves through the pipeline one stage at a time, with the Orchestrator proposing each transition for your approval.
## The five stages
### Ideation
You brief the Orchestrator on your idea, and the Ideation Agent takes over as a Socratic questioner. Rather than agreeing with everything, it probes the idea, logs your assumptions explicitly, and maintains a list of open questions. The output is a sharper idea and an honest record of what you do not yet know.
### Research (Discover)
The Research Agent turns open questions into cited findings. It draws on multiple sources: web search via Exa, Reddit, G2 and Trustpilot reviews, app stores, and GitHub, and it can run surveys. Because findings land in the shared project context, every later stage builds on them.
### PRD / Define
The PRD Agent writes the product requirements document, but only after you approve its outline. It then drafts section by section. Four templates are available:
| Template | Sections |
| -------------------- | -------- |
| ProductOS Standard | 10 |
| Amazon PRFAQ | 8 |
| Lean | 6 |
| Enterprise/Regulated | 12 |
Optionally, the Architect Agent extends the Define stage with 8 architecture sections, architecture decision records (ADRs), and infra cost estimates.
### Design
Two agents share this stage. The Design Agent produces user flows and screen specs. The Design System Agent generates design tokens, a DESIGN.md, and HTML previews in both dark and light themes. Together they give the build stage a concrete, reviewable visual target before any application code is written.
### Develop
The Fullstack Builder, a real coding agent, works headlessly inside your project's sandbox. Code appears in a live preview as it is written, and it syncs continuously to your own GitHub repository. See [Code ownership](/docs/platform/code-ownership).
## QA and Deploy: actions, not stages
QA and Deploy sit outside the stage sequence. Trigger them on demand, at any point, as often as you need.
* **QA** runs your app in a real headless Chromium browser: flows, per-route screenshots, API checks, and an axe accessibility audit. It returns a verdict of pass, partial, or fail, and a fail can chain into an auto-fix run.
* **Deploy** checks for a recent deploy first, runs a preflight build, pushes to GitHub, and deploys to Vercel with up to 3 self-fix iterations. Apps ship to `{slug}.product-os.app` or a custom domain.
## Sandboxes: where projects run
Each project runs in an isolated cloud sandbox (powered by Blaxel) with a live preview URL. The sandbox is where agents install dependencies, write files, and run builds, so nothing touches your machine and you can watch progress in the embedded preview.
## Starting from a template
You do not have to start from a blank idea. Curated templates (for example SOLEN, Echo, StudioFlow, Lumen Notes, and Orbit on the Code surface) clone into a fresh private project you fully own. Volume-backed templates boot in about 3 seconds, versus about 25 seconds for tarball-based ones. Browse the full directory at [productos.dev/templates](https://productos.dev/templates), which lists 14 templates.
## Next steps
* [Pricing overview](/docs/pricing/overview): products, named licenses, and included AI capacity
* [Build surface overview](/docs/build/overview): the full pipeline in depth
# Quickstart
Source: https://productos.dev/docs/getting-started/quickstart
Go from a one-line idea to a researched, specced, designed, and deployed product. Free tier, no credit card required to start.
This guide takes you from signup to a live product using the Build surface, the flagship full pipeline. It should feel less like operating a tool and more like briefing a team.
Sign up at [beta.productos.dev](https://beta.productos.dev/sign-up). The free tier includes monthly credits and no credit card is required. One account works across Build, Code, and Design, with a single shared credit pool.
Start a project and tell the Orchestrator what you want to build, in plain language. The Orchestrator is the only agent that talks to you; it routes your request to the right specialist and proposes each stage transition for your approval.
The Ideation Agent works like a Socratic questioner: it probes the idea, logs your assumptions, and keeps a list of open questions. You leave this stage with a clearer idea than you arrived with.
Delegate research from the chat. The Research Agent runs multi-source, cited research: web search via Exa, Reddit threads, G2 and Trustpilot reviews, app stores, and GitHub. It can also run surveys. Findings land in the shared project context, where every later stage can use them.
The PRD Agent first proposes an outline for your approval, then writes section by section. Choose from four templates: ProductOS Standard (10 sections), Amazon PRFAQ (8), Lean (6), or Enterprise/Regulated (12). Optionally, the Architect Agent adds 8 architecture sections, ADRs, and infra cost estimates.
The Design Agent produces user flows and screen specs. The Design System Agent generates design tokens, a DESIGN.md, and dark plus light HTML previews, so the build stage has a concrete visual target.
In the Develop stage, the Fullstack Builder codes your app headlessly inside an isolated cloud sandbox with a live preview URL. Generated code syncs to your own GitHub repository as it is written.
QA and Deploy are actions, not stages: run them whenever you like. The QA Agent drives a real headless Chromium browser through your flows, captures per-route screenshots, checks APIs, and runs an axe accessibility audit, returning a pass, partial, or fail verdict. A fail can chain into an auto-fix run. The Deploy Agent then runs a preflight build, pushes to GitHub, and deploys to Vercel with up to 3 self-fix iterations, shipping to `{slug}.product-os.app` or your own custom domain.
In a hurry, or building something smaller? Start on the [Code surface](/docs/code/overview) instead: describe the app or clone a curated template, and build directly in a live sandbox.
## Next steps
* [Core concepts](/docs/getting-started/core-concepts): how shared context, the pipeline, and agents fit together
* [Projects and stages](/docs/getting-started/projects-and-stages): what each stage produces
* [Pricing overview](/docs/pricing/overview): how usage is billed and which plan fits your situation
# What is ProductOS?
Source: https://productos.dev/docs/getting-started/what-is-productos
ProductOS is an AI-native product development platform: describe an idea once and a team of AI agents researches, specs, designs, codes, and ships it.
ProductOS is an AI-native product development platform. You describe an idea once; a team of specialized AI agents researches it, writes the PRD, designs it, codes it, and deploys it. Every agent works from the same project context, so nothing gets lost between stages: the research informs the PRD, the PRD informs the design, and the design informs the code.
## One idea, one shared context
Most AI tools handle a single slice of product work. You research in one tool, spec in another, design in a third, and paste context between them. ProductOS replaces that relay race with a single pipeline:
```
Ideation -> Research -> PRD -> Design -> Develop
```
An Orchestrator agent routes all work and is the only agent that talks to you. It proposes stage transitions for your approval, then hands the shared context to the specialist for that stage. QA and deployment are on-demand actions you can trigger whenever you want to verify or ship.
## The agent team
A Socratic Ideation Agent sharpens the idea and logs assumptions. The Research Agent runs multi-source, cited research across the web, Reddit, review sites, app stores, and GitHub.
The PRD Agent writes section by section behind an outline-approval gate, with four templates. An optional Architect Agent adds architecture sections, ADRs, and infra cost estimates.
Design agents produce user flows, screen specs, design tokens, and dark plus light HTML previews. A Fullstack Builder codes the app headlessly in your project sandbox.
The QA Agent tests your app in a real headless browser, including an accessibility audit. The Deploy Agent ships to a live URL with up to 3 self-fix iterations.
## Three surfaces, one account
| Surface | URL | What it does |
| ---------- | ------------------------------------------------------ | --------------------------------------------------------- |
| **Build** | [beta.productos.dev](https://beta.productos.dev) | The flagship full pipeline, from idea to deployed product |
| **Code** | [develop.productos.dev](https://develop.productos.dev) | AI app builder with a live cloud sandbox |
| **Design** | [design.productos.dev](https://design.productos.dev) | UI generation and templates |
One account works everywhere, and your credits are shared across all three surfaces.
## You own the code
Generated code syncs to your own GitHub repository as it is written. You can export everything at any time. There is no lock-in: the output is a standard codebase you can take anywhere. See [Code ownership](/docs/platform/code-ownership).
## Where your work runs
Projects run in isolated cloud sandboxes with live preview URLs, so you watch the app take shape as agents build it. Your project context (PRD, research, designs) is also available in Cursor and Claude over [MCP](/docs/integrations/mcp), so you can keep building in your own tools.
## Start free
There is a free tier and no credit card is required to start. Sign up at [beta.productos.dev](https://beta.productos.dev/sign-up), then follow the [quickstart](/docs/getting-started/quickstart).
# Claude
Source: https://productos.dev/docs/integrations/claude
Connect Claude to your ProductOS project over MCP so it plans, specs, and pressure-tests decisions against your real product context.
The ProductOS Claude integration connects Claude to your project over [MCP](/docs/integrations/mcp), so Claude reasons over the real product context: no copy-paste, no re-explaining the product every session, no drift.
## What Claude sees
* **The PRD.** Claude reads the live requirements: scope, user stories, and acceptance criteria, so its plans and answers are grounded in what you are actually building.
* **The research.** Market and user findings are part of the context, so Claude reasons with the evidence behind the product instead of generic assumptions.
* **The design.** Flows and UI decisions are visible to Claude, keeping its suggestions consistent with the intended experience.
Depending on the access level you grant, Claude can also work in the project's cloud sandbox — read and edit files, run commands, and deploy. See the [tools reference](/docs/integrations/mcp-tools) for the full list.
## Why connect Claude
Teams reach for Claude to plan, spec, and reason through hard product decisions. The missing piece has always been context:
* **No copy-paste.** No more pasting the PRD into a chat and re-explaining the product every session. The MCP connection lets Claude read the live context straight from ProductOS.
* **Grounded reasoning.** When Claude can see the requirements and the research, its output stops drifting. You get analysis and drafts that hold up against the actual product definition.
* **Results flow back.** MCP is bidirectional, so updates Claude makes are written back into the shared context where the rest of the pipeline can use them.
## Connect Claude
The server URL is the same for everyone:
```text theme={null}
https://beta.productos.dev/api/mcp/connect
```
In **Claude.ai** or **Claude Desktop**, open Settings → Connectors → **Add custom connector** and paste the URL above.
In **Claude Code**, run:
```bash theme={null}
claude mcp add --transport http productos https://beta.productos.dev/api/mcp/connect
```
Claude opens a browser to sign you in. Pick which organization or projects the connection can reach, and at what level: read, read and write, or full development.
Ask Claude to refine the spec, pressure-test a flow, or draft the next iteration.
There is no project id in the URL. You choose what the connection can reach while authorizing, so the same endpoint works for every account. To revoke a connection later, or to mint an API key instead of using the browser flow, open **Settings → MCP Access** in ProductOS.
## What connected Claude is good at
* **Refine the spec in place.** Ask Claude to sharpen user stories or acceptance criteria and it edits against the real PRD, not a copy.
* **Pressure-test decisions.** Have Claude challenge a product choice using the research that is already in your project context.
* **Plan the next iteration.** Draft the roadmap for what comes next with Claude reasoning over where the product actually stands today.
## Claude vs Cursor: which one?
Both integrations expose the same project over the same protocol and the same endpoint. The difference is where you work: Cursor is the editor, where the connected context steers code generation; Claude is where you plan, spec, and reason before and between builds. Many teams use both, and because they read one shared context, nothing diverges between them. See the [Cursor integration](/docs/integrations/cursor).
Whatever you produce with Claude connected remains yours. The code side of the pipeline syncs to your own repository through the [GitHub integration](/docs/integrations/github).
# Cursor
Source: https://productos.dev/docs/integrations/cursor
Connect ProductOS to Cursor over MCP so the editor writes code against your real PRD, research, and design instead of a pasted snippet.
The ProductOS Cursor integration exposes your project over [MCP](/docs/integrations/mcp) so Cursor can read everything the pipeline already knows. Ask Cursor to build a feature and it reasons over your real PRD, research, and design, with the results written back where the rest of the pipeline can use them.
## What Cursor sees
Three parts of your project context come with the connection:
* **The PRD.** Cursor reads the live product requirements: scope, user stories, and acceptance criteria, so generated code answers to the spec instead of guessing.
* **The research.** Market findings and user insights come along, so implementation decisions carry the reasoning behind the product.
* **The design.** Flows and UI decisions are visible to the editor, keeping the code you write aligned with the intended experience.
Depending on the access level you grant, Cursor can also work in the project's cloud sandbox — read and edit files, run commands, provision a database, and deploy. See the [tools reference](/docs/integrations/mcp-tools) for the full list.
## Why connect Cursor
PMs and technical founders increasingly live in Cursor. The problem is not the editor; it is that the editor does not know what you are actually building. The MCP connection closes that gap:
* **No copy-paste.** Stop pasting your PRD into the chat pane and hoping it sticks. Cursor pulls the live context directly from your ProductOS project.
* **Spec-true generation.** When the assistant can see the requirements, its suggestions stop drifting. You get code that matches the product you defined, not a plausible-looking tangent.
* **Always current.** Because the context is live, changes to the product definition surface in the editor instead of going stale.
## Connect Cursor
The server URL is the same for everyone:
```text theme={null}
https://beta.productos.dev/api/mcp/connect
```
Open Settings → **Cursor Settings** → **MCP** → **Add new MCP server** and paste the URL above.
You can also commit it to the project by creating `.cursor/mcp.json`:
```json theme={null}
{
"mcpServers": {
"productos": {
"url": "https://beta.productos.dev/api/mcp/connect"
}
}
}
```
Cursor opens a browser to sign you in. Pick which organization or projects the connection can reach, and at what level: read, read and write, or full development.
Ask Cursor to build a feature and it reasons over your real PRD, research, and design.
There is no project id in the URL. You choose what the connection can reach while authorizing, so the same endpoint works for every account. To revoke a connection later, or to mint an API key for CI instead of using the browser flow, open **Settings → MCP Access** in ProductOS.
## What context in the editor unlocks
* **Implement to the spec.** Point Cursor at a user story and let it build the feature against the acceptance criteria already in your PRD.
* **Answer product questions in context.** Ask why a flow works the way it does and get an answer grounded in the research, not the model's imagination.
* **Keep code and product in sync.** The live connection means the editor and the product definition never diverge silently.
You do not have to be technical to use this integration. It brings the PRD, research, and design into the editor, so a product manager can direct Cursor with the same source of truth an engineer uses: you describe what you want, and Cursor builds against the spec.
## Ownership is unchanged
The integration is about access, not lock-in. Whatever Cursor produces is your code. You can sync the full codebase to your own GitHub repo through the [GitHub integration](/docs/integrations/github) and deploy it anywhere.
Prefer to reason and plan before you code? The same connection works with the [Claude integration](/docs/integrations/claude).
# GitHub
Source: https://productos.dev/docs/integrations/github
Sync the full generated codebase to your own GitHub repository as real commits, review real diffs, and deploy from the branch you control.
The GitHub integration is the exit of the ProductOS pipeline. Research, PRD, and design produce the shared context; the coding agents turn it into a real codebase; GitHub sync puts that codebase in your hands. Generated code syncs to your own repository as it is written, so ownership is the default state, not an export feature.
## What you get
* **Full code sync.** The complete generated codebase lands in your GitHub repository. Not a snippet or a sandbox, but the real project, structured the way an engineer would expect.
* **Real diffs to review.** Every change ProductOS makes shows up as a commit you can read, review, and revert. Your team reviews product changes the same way they review any code.
* **Export anytime.** There is no export wall. Pull the codebase down whenever you want and keep it forever, whether or not you keep using ProductOS.
## Why it works this way
* **No lock-in by design.** Many AI app builders trap the output behind their platform. ProductOS does the opposite: the code lives in your repo from the start, so leaving is never a migration project.
* **Own every line.** You hold the repository, the history, and the right to take the code anywhere. See [Code ownership](/docs/platform/code-ownership).
* **Fits your engineering workflow.** Because it is just Git, the code drops into the branching, review, and CI conventions your team already runs. There is no proprietary workflow to learn.
## Connect in three steps
Authorize ProductOS from your project's integration settings and choose the account or organization that will own the repository.
Sync into an existing repository or let ProductOS create a fresh one. The full codebase is pushed to the branch you choose.
Review the diffs, merge, and deploy straight from GitHub to your own hosting. Every subsequent change syncs back as normal commits.
## What the repo unlocks
* **Deploy from GitHub.** Wire the repo to your host of choice and ship from the branch you control, with previews on every push. The [Deploy Agent](/docs/agents/deploy) also pushes to GitHub as part of its own deploy flow.
* **Bring engineers into the loop.** Hand the repo to your team so they can review, extend, and harden the generated code with the tools they already use.
* **Keep an auditable history.** Every change is a commit, so you always have a full record of how the product evolved.
Yes. The repository, its history, and the code inside it are yours. You can keep the codebase, take it to another host, or continue developing it independently whether or not you keep using ProductOS.
Yes. Because the full codebase lives in your GitHub repo, you can connect it to your hosting provider and deploy from the branch you control. Further changes from ProductOS arrive as normal commits.
No. GitHub sync is part of the core ProductOS workflow, and you can start on the free tier.
# MCP
Source: https://productos.dev/docs/integrations/mcp
What the Model Context Protocol is, why ProductOS integrates over it, and what your project exposes to connected clients — from live context to the full 58-tool coding surface.
The Model Context Protocol (MCP) is an open standard that lets AI clients read from and write to external context sources through one consistent interface. A service implements the protocol once, and any MCP-capable client, such as Cursor or Claude, can discover and use it without custom integration code.
ProductOS uses MCP to expose your project as a live context source — and, beyond context, as a full remote development environment. Instead of pasting your PRD into a chat window and hoping it sticks, you connect the tool once, and it works against the actual product context.
## What ProductOS exposes over MCP
Your ProductOS project context is available in Cursor and Claude over MCP. That context includes:
| Context | What the connected tool sees |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **The PRD** | Live product requirements: scope, user stories, and acceptance criteria, so generated code and analysis answer to the spec instead of guessing. |
| **The research** | Market findings and user insights, so implementation and product decisions carry the reasoning behind the product. |
| **The designs** | Flows and UI decisions, keeping output aligned with the intended experience. |
Because both clients read the same source, whatever you open sees the same requirements and the same constraints. The context is live: changes to the product definition surface in the connected tool instead of going stale.
## Beyond context: the full tool surface
Context is only part of the connection. The ProductOS MCP server also exposes your project's cloud sandbox — files, a shell, sandbox lifecycle, databases and storage, GitHub sync, deployments, a headless browser, mobile publishing, and multi-surface Product orchestration. That's **58 tools**, each gated behind the scope you grant the connection (`project:read`, `project:write`, or `project:exec`), so a connected agent can go from reading your spec to editing files, running builds, and shipping to production — all remote, with no local clone.
Connected clients also get your **skills** — the reusable playbooks ProductOS ships (cloning a website, an SEO pass) plus any your workspace defines. They arrive as tools, as `/slash` commands, and as attachable `skill://` resources, so an external agent follows the same playbook the in-app agents do.
See the [MCP tools reference](/docs/integrations/mcp-tools) for the complete list, grouped by category with the scope each tool requires.
## Why a protocol instead of copy-paste
* **Context, not snapshots.** A pasted PRD is a stale copy the moment you paste it. Over MCP, the client reads the current state of your project every time.
* **One source of truth.** Cursor and Claude both work from the same shared context, so there is no drift between the tool where you plan and the tool where you code.
* **Bidirectional by design.** MCP is a two-way channel. Tools can read your product context and write work back into it, so refinements you make in the editor land where the rest of the pipeline can use them.
## Connecting a client
The connection flow is the same for any MCP client:
Pick the project whose context you want to expose and open its integration settings to reveal the MCP connection.
Add the ProductOS MCP endpoint to the client's MCP configuration (Cursor's MCP configuration, or Claude's connector settings) and authorize it.
The client now treats your ProductOS project as a context source it can read and write.
Client-specific walkthroughs: [Cursor](/docs/integrations/cursor) and [Claude](/docs/integrations/claude).
The MCP connection is part of the core ProductOS workflow. You can start free; no paid plan is required to connect Cursor or Claude.
## MCP and code ownership
MCP handles context; [GitHub sync](/docs/integrations/github) handles code. Whatever a connected tool produces is your code, and the full codebase syncs to your own GitHub repository. Together the two integrations mean neither your product context nor your code is trapped inside ProductOS. See [Code ownership](/docs/platform/code-ownership).
# MCP tools reference
Source: https://productos.dev/docs/integrations/mcp-tools
Every tool the ProductOS MCP server exposes to connected AI clients — 58 tools across files, shell, skills, sandboxes, databases, deployments, browser automation, mobile publishing, and multi-surface Product orchestration.
The ProductOS MCP server exposes your entire project — not just its context — to any MCP client such as Claude, ChatGPT, Cursor, Windsurf, or VS Code. Beyond reading your PRD, research, and designs, a connected agent gets the full project sandbox: files, a shell, reusable skills, sandbox lifecycle, databases and storage, GitHub sync, deployments, a headless browser, mobile publishing, and multi-surface Product orchestration — **58 tools in total**.
Every tool is project-scoped and permission-gated. A connection carries one or more scopes, and each tool requires at least one:
| Scope | Grants |
| --------------- | ----------------------------------------------------------------- |
| `project:read` | Read project context, files, status, and logs |
| `project:write` | Create or modify files, projects, infrastructure, and deployments |
| `project:exec` | Run a shell, manage packages, and drive a headless browser |
You choose the scope per project (or org-wide) when you connect. A read-only connection can never write, and a write is refused mid-session if the grant is downgraded or you lose access to the project.
## Project and workspace
| Tool | Scope | What it does |
| ----------------------- | ----- | ----------------------------------------------------------------------------------------------------------- |
| `get_project_context` | read | Project overview: stage, PRD, and design notes from the wiki |
| `get_project_metadata` | read | Type and framework, GitHub repo and branch, database and storage provisioning, sandbox id, and access level |
| `list_projects` | read | Every project the connection can access, each with its level, and the active one |
| `list_organizations` | read | Workspaces the connection spans and your role in each |
| `list_available_repos` | read | Context repositories that can be attached to the project |
| `open_project` | write | Set the active project and boot its sandbox, returning a live preview URL |
| `create_project` | write | Create a new project: registry entry, GitHub repo, and template image |
| `clone_project` | write | Duplicate a project's docs, settings, and stage data into a new project |
| `delete_project` | write | Delete a project and reap its sandbox and volume |
| `set_project_framework` | write | Set the project's framework or template |
| `add_context_repo` | write | Attach an external repository as project context |
## Files and code
All file tools operate on the project's cloud sandbox at `/home/user`. Every mutation auto-commits to GitHub, so changes survive sandbox recreation.
| Tool | Scope | What it does |
| ------------------------ | ----- | ----------------------------------------------- |
| `read_file` | read | Read a file from the sandbox, as text or base64 |
| `list_files` | read | List a directory in the sandbox |
| `read_project_structure` | read | One-shot recursive file tree, pruned |
| `search_files` | read | Regex content search across the project (grep) |
| `find_files` | read | Find files by name or glob |
| `write_file` | write | Create or overwrite a file, text or base64 |
| `edit_file` | write | Targeted string-replace edits within a file |
| `move_file` | write | Rename or move a file or directory |
| `delete_file` | write | Delete a file or directory |
## Knowledge and memory
| Tool | Scope | What it does |
| -------------------- | ----- | --------------------------------------------- |
| `search_memory` | read | Semantic search over the project's memory |
| `list_decisions` | read | Logged PRD and design decisions |
| `get_decision` | read | Fetch a single logged decision |
| `remember_fact` | write | Persist a durable fact into project memory |
| `write_wiki_section` | write | Write or update a section of the project wiki |
| `write_prd_section` | write | Write or update a section of the PRD |
## Skills
Skills are reusable playbooks — step-by-step instructions for work that recurs, such as cloning a website, running an SEO pass, or following your team's own conventions. The in-app agents receive them automatically; these tools are how a connected external client gets them too.
A connection sees three kinds at once:
* **Built-in skills** that ship with ProductOS — the same methodologies its own agents run on: `web-development`, `code-review`, `seo-optimization`, `analytics`, `aws-deployment`, `quality-standards`, `clone-website`, `browser-automation`.
* **Workspace skills** your team writes, shared across every project.
* **Project skills** scoped to one project.
Workspace and project skills are managed in the app under **Settings → Skills**. Where a skill you define shares a slug with a built-in, yours takes precedence — that's how you customise a built-in without losing it.
| Tool | Scope | What it does |
| -------------- | ----- | ------------------------------------------------------------------------------------------------- |
| `list_skills` | read | Every skill this connection can use, with a description and scope; filterable by name or category |
| `get_skill` | read | The full instructions for one skill, as a `SKILL.md` document to follow |
| `create_skill` | write | Save a new skill into this workspace or project, optionally offering it to the platform |
### Writing a skill back
When an agent works out a procedure worth keeping, `create_skill` saves it so the next session starts from it. The new skill is usable in your workspace immediately.
Publishing to *every* workspace is not self-service: set `submit_to_platform: true` (or press **Submit to platform** in Settings → Skills) and the skill enters a review queue. A ProductOS admin then publishes a platform copy or declines with a reason. Either way you keep your own copy, and a published skill arrives opt-in rather than always-on.
The same skills are exposed through two other MCP surfaces, so you can reach them whichever way your client prefers:
* **Prompts** — each skill is a slash command: `/clone-website` in Claude Code, `/mcp-productos-clone-website` in Cursor. Pass what you want it applied to as the `input` argument, e.g. a URL. Up to 40 skills are registered this way; the rest stay available through `list_skills`.
* **Resources** — each skill is readable at `skill://`, so clients with an @-mention picker can attach one as context.
A connected agent can read any skill it is entitled to and create new ones, but it cannot edit or delete existing skills, and it cannot publish anything platform-wide on its own. Those stay in the ProductOS app and the admin console.
## Shell and dependencies
| Tool | Scope | What it does |
| --------------------- | ----- | ---------------------------------------------------------------------- |
| `bash` | exec | Full shell in the sandbox: pipes, `&&`, globs, git, npm, tsc, and node |
| `manage_dependencies` | exec | Add, remove, or install npm packages |
## Sandbox lifecycle
| Tool | Scope | What it does |
| -------------------- | ----- | --------------------------------------------------------------------------- |
| `get_sandbox_status` | read | Instance status, dev-server health, live preview URL, and last-active time |
| `get_sandbox_urls` | read | Preview, dev, and IDE URLs (Expo-aware) |
| `get_sandbox_logs` | read | Tail the dev-server logs |
| `start_sandbox` | write | Boot or restore the sandbox and return its URLs |
| `stop_sandbox` | exec | Delete the sandbox instance; GitHub and the persistent volume are preserved |
| `restart_sandbox` | exec | Restart the dev server, or hard-recreate the sandbox |
## Git and GitHub
| Tool | Scope | What it does |
| ---------------- | ------------ | -------------------------------------------------------------------- |
| `git_sync` | read / write | Show working-tree status and recent commits, or commit-push and pull |
| `push_to_github` | write | Push the latest project files to GitHub as a commit |
## Databases, storage, and environment
| Tool | Scope | What it does |
| -------------------- | ----- | ------------------------------------------------------------------------------- |
| `provision_database` | write | Provision a Postgres database (Neon) and wire `DATABASE_URL` and Prisma |
| `provision_storage` | write | Provision isolated file storage and write credentials into the sandbox env |
| `manage_env_vars` | write | List (keys only), set, or delete environment variables and sync the sandbox env |
## Deployment and diagnostics
| Tool | Scope | What it does |
| ------------------- | ----- | ------------------------------------------------------- |
| `trigger_deploy` | write | Kick off a production deployment |
| `get_deploy_status` | read | Latest production deployment status and URL |
| `get_deploy_logs` | read | Build and deploy logs and error detail for a deployment |
## Browser automation
A headless Chromium runs inside the sandbox, so an agent can drive and inspect the app it is building. These tools require `project:exec`.
| Tool | Scope | What it does |
| -------------------- | ----- | ---------------------------------------------------------------------------- |
| `browser_navigate` | exec | Navigate the sandbox's Chromium to a URL |
| `browser_snapshot` | exec | Accessibility-tree snapshot with refs to act on |
| `browser_read` | exec | Read visible text, HTML, an input value, an attribute, the title, or the URL |
| `browser_screenshot` | exec | Capture the page as an image |
| `browser_act` | exec | Click, double-click, hover, fill, type, select, check, press keys, or scroll |
| `browser_tabs` | exec | List, open, switch, or close browser tabs |
| `browser_debug` | exec | Read console output, uncaught exceptions, or captured network requests |
## Mobile publishing
| Tool | Scope | What it does |
| -------------------- | ------------ | ------------------------------------------------------------------------------------------ |
| `mobile_publish` | read / write | The Expo and EAS pipeline: app identity, EAS build, and App Store or Play Store submission |
| `get_eas_build_logs` | read | Real failure logs for a mobile EAS build (the Run gradlew or Xcode phase) |
## Product mode
A Product groups several platform surfaces (web, mobile, website) that share one frozen spec, one database, and one orchestrator agent.
| Tool | Scope | What it does |
| --------------------- | ------------ | ------------------------------------------------------------------------------------------------------------- |
| `get_product_context` | read | Orient in a Product: sibling surfaces, whether the shared spec is frozen, and what the orchestrator is doing |
| `read_shared_context` | read | Read the frozen shared contract every surface is built against (PRD, flows, components, tokens, schema) |
| `manage_product` | write | Create or steer a Product: provision the shared database and build the web, mobile, and website surfaces |
| `product_agent` | read / write | Read and drive the ProductOS orchestrator that plans, freezes the contract, and dispatches per-surface builds |
## Connecting
Connect the ProductOS MCP server to any client over OAuth: paste the endpoint, sign in, and choose which project or organization the connection can reach and at what scope. See the client walkthroughs for [Cursor](/docs/integrations/cursor) and [Claude](/docs/integrations/claude), or the [MCP overview](/docs/integrations/mcp) for how the protocol fits into ProductOS.
Tool availability follows your scope. A `project:read` connection sees only the read tools above; `project:write` adds the write tools; `project:exec` adds the shell and browser tools.
# Integrations overview
Source: https://productos.dev/docs/integrations/overview
Connect your ProductOS project to any MCP client — Claude, ChatGPT, Cursor, Windsurf, or VS Code — and sync the full generated codebase to your own GitHub repository.
ProductOS integrations exist to keep your product context intact as it moves between tools. The research, PRD, and design your agents produce form a single record of what you are building and why. Integrations carry that record into the editor you code in and the repository you own, instead of leaving it behind as pasted text.
## What's available
The protocol behind every client integration. Connect any MCP client to your project's live context and its cloud sandbox.
All 58 tools a connected client can use, grouped by category, with the scope each one requires.
Pull your PRD, research, and design context into Cursor over MCP, so the code you write in the editor stays true to the spec.
Connect Claude to your ProductOS project over MCP and reason over the real product context, with no copy-paste and no drift.
Sync the full generated codebase to your own GitHub repo, review real diffs, and deploy from the branch you control.
Cursor and Claude have their own walkthroughs, but the MCP server is not limited to them — **any MCP-capable client works**, including ChatGPT, Windsurf, and VS Code.
Vercel, Figma, and Slack integrations are on the roadmap: one-click deploys to your own Vercel project, round-tripping generated screens into Figma, and pushing research findings, PRD updates, and ship notifications into Slack channels.
## Connect over MCP
Every client connects to the same endpoint:
```text theme={null}
https://beta.productos.dev/api/mcp/connect
```
Most clients take the URL on its own and open a browser to authorize. For clients configured with a JSON file, the entry looks like this:
```json theme={null}
{
"mcpServers": {
"productos": {
"url": "https://beta.productos.dev/api/mcp/connect"
}
}
}
```
Paste the URL into your client's MCP configuration — Cursor's MCP settings, Claude's connector settings, or the equivalent.
The client opens a browser to sign you in. You then pick which organization or projects the connection can reach, and at what level: read, read and write, or full development.
The client can now read your project and, depending on the level you granted, edit files, run commands, and deploy.
You do not put a project id in the URL. The connection resolves to whatever you select while authorizing, so one endpoint works for every account. To manage or revoke a connection later — or to mint an API key for a script or CI instead of using the browser flow — open **Settings → MCP Access** in ProductOS.
The access level you choose is a hard ceiling. A read-only connection can never write, and a write is refused mid-session if you lose access to the project. See the [tools reference](/docs/integrations/mcp-tools) for which scope each tool requires.
## Why MCP
Clients connect over the Model Context Protocol (MCP), an open standard for connecting AI assistants to real context sources. Instead of shipping your product context around as pasted text, ProductOS exposes it as a live source those tools can read and write:
* **Context, not copy-paste.** The AI client reads your live ProductOS project, the brief, the PRD, and the design decisions, instead of a stale snapshot you pasted into a prompt.
* **One source of truth.** Every connected client reads the same shared context. Whichever tool you open, the assistant sees the same requirements and constraints.
* **Bidirectional by design.** MCP is a two-way channel. Tools can read your product context and write work back into it, so nothing you do in the editor gets lost.
* **More than context.** The same connection exposes the project's cloud sandbox — files, a shell, databases, deployments, and a headless browser — so a client can build and ship, not just read.
* **Your team's playbooks travel too.** Skills — the reusable procedures ProductOS ships and the ones your workspace writes — reach a connected client as tools, slash commands, and attachable resources, so an external agent follows the same method your in-app agents do.
Read more in [What is MCP](/docs/integrations/mcp).
## How integrations fit the pipeline
Research, PRD, and design agents produce the shared context: the single record of what you are building and why.
Connect your client over MCP and code, refine, or reason against that live context instead of a blank page.
Sync the full codebase to your repo, review real diffs, and deploy from the branch you control. There is no export wall.
Integrations are the entrances and exits of the ProductOS pipeline, not bolt-ons. GitHub in particular exists to reduce lock-in: the complete codebase lands in your own repository, you can export it at any time, and you deploy it wherever you like. See [Code ownership](/docs/platform/code-ownership).
## Do integrations cost extra?
No. You can start free, and both the MCP connection and the GitHub code sync are part of the core ProductOS workflow. Connect them from your project settings and start pulling context into your tools.
# BYOK and models
Source: https://productos.dev/docs/platform/byok-and-models
Bring your own Anthropic, OpenAI, Google, or OpenRouter key and run credit-free, and choose which model each agent uses.
ProductOS is multi-provider by design. No model is hardcoded anywhere in the platform: every agent resolves its model from configuration, and you can override that configuration per agent. You can also bring your own API keys and run on them instead of platform credits.
## Bring your own key (BYOK)
Instead of consuming platform credits, you can plug in your own provider keys:
* **Anthropic**, **OpenAI**, or **Google** keys for direct access to that provider's models
* An **OpenRouter** gateway key, which can route any model through your OpenRouter account
Add keys under **Settings → Providers**. Runs that use your key skip credit deduction entirely; token usage is still logged so your usage history stays complete.
BYOK keys are stored AES-256-GCM encrypted in the shared account database and work across all surfaces. The raw key is never returned to the client after you save it; only the last four characters are shown.
## How requests are routed
When an agent makes a model call, ProductOS picks the route in a fixed order of precedence:
1. **Native key.** If you have a key for the model's own provider (for example, an Anthropic key and a Claude model), the call goes directly to that provider on your key, credit-free.
2. **Gateway key.** If you have an OpenRouter gateway key, any model can route through your gateway, credit-free.
3. **Platform default.** With no matching key, the call runs on platform infrastructure and is metered in credits.
You do not manage this routing manually; connecting a key is enough for eligible calls to use it.
## Per-agent model selection
Each agent has a default model configured by platform admins, chosen to suit its work: research, long-form writing, and code generation have different demands, and the defaults reflect that. Under the hood the platform routes across multiple providers, including Anthropic, OpenAI, Google, xAI, and Perplexity models.
You can override the model for any individual agent in **Settings → Per-Agent Model Overrides**. The picker is a searchable combobox grouped by provider:
* A **ProductOS** group with the platform's model catalog
* One group per **connected provider**, populated live from that provider's own model list using your key
Resolution order is simple: your per-agent override wins, otherwise the admin-configured default applies. Picking a model from a connected provider's group routes that agent through your key, credit-free.
A practical setup: connect one provider key for the models you care most about (for example, your coding agent), and let everything else run on platform defaults. You only override what you want to control.
## Related pages
* [AI credits and models](/docs/pricing/ai-credits-and-models): included capacity, model tiers, top-ups, and BYOK behavior
* [Security and data](/docs/platform/security-and-data): how keys and data are protected
# Code ownership
Source: https://productos.dev/docs/platform/code-ownership
Everything ProductOS generates is yours: code syncs to your own GitHub repo as it is written, with full export and no lock-in.
ProductOS is built on a simple principle: the output belongs to you. Agents do the work, but the code, the PRD, the research, and the designs are your assets, in formats you can take anywhere.
## Your code lives in your GitHub repo
Generated code syncs to your own GitHub repository as it is written, not as a one-time export at the end. While the Fullstack Builder works in the project sandbox, the codebase accumulates in a repo you control, under your account, with your access rules.
This has practical consequences:
* **No export step to remember.** The repo is always current with what the agents have built.
* **Normal tooling works.** Clone the repo, open it in your editor, run it locally, wire up your own CI. It is a standard codebase, not a proprietary bundle.
* **Deploys go through your repo.** The Deploy Agent pushes to GitHub before deploying to Vercel, so what is live always corresponds to a commit you can see.
## Full export, no lock-in
You can export your project in full at any time. There is no proprietary runtime your app depends on and no format you have to convert out of. If you stop using ProductOS tomorrow, you keep a working codebase, your PRD, your research, and your design specs.
Templates follow the same rule: a curated template clones into a fresh private project that is entirely yours to modify, own, and ship.
## More than code
Ownership extends to the whole shared project context:
| Asset | What you get |
| -------- | ----------------------------------------------------------------- |
| Code | Synced to your GitHub repo, fully exportable |
| PRD | A structured document you approved section by section |
| Research | Multi-source findings with citations |
| Designs | User flows, screen specs, design tokens, DESIGN.md, HTML previews |
Your project context is also available in Cursor and Claude over [MCP](/docs/integrations/mcp), so external tools can read the same PRD, research, and designs your agents work from. The platform is useful because of what it does, not because it holds your work hostage.
## Working outside ProductOS
A common pattern: let ProductOS carry a project through research, PRD, design, and the first working build, then continue development in your own environment against the synced repo. Nothing about the generated code assumes ProductOS is still in the loop. You can also keep both going, using ProductOS for agent-driven features and your editor for hand-written changes, since both operate on the same repository.
## Related pages
* [GitHub sync](/docs/code/github-sync): how the sync works on the Code surface
* [Deployments and domains](/docs/platform/deployments-and-domains): how shipping works
* [Security and data](/docs/platform/security-and-data): where your data lives
# Deployments and domains
Source: https://productos.dev/docs/platform/deployments-and-domains
How ProductOS ships your app: sandbox previews while you build, then a self-checking deploy to a live URL or your own custom domain.
Your app is visible from the first file written and shippable whenever you decide it is ready. Two mechanisms make that work: sandbox previews during development, and the Deploy Agent when you want to go live.
## Live previews while you build
Every project runs in an isolated cloud sandbox with a live preview URL. As agents write files, install dependencies, and run builds, the preview updates, so you review real behavior rather than descriptions of it. Previews are for development; they are not your production URL.
## Deploying
Deploy is an on-demand action, not a pipeline stage: trigger it whenever you want, as often as you want. When you do, the Deploy Agent runs a sequence designed to ship a working app, not just push files:
The agent first checks whether a recent deploy already covers the current state, avoiding redundant work.
It builds the project before anything ships. Problems surface here, not in production.
The code is pushed to your own GitHub repository, so every deploy corresponds to a commit you can inspect. See [Code ownership](/docs/platform/code-ownership).
The app deploys to Vercel and comes up at its live URL.
If the build or deploy fails, the agent does not just report the error: it attempts to fix the problem itself, with up to 3 self-fix iterations before it hands the issue back to you.
Run [QA](/docs/build/qa) before deploying. The QA Agent tests your app in a real headless browser and returns a pass, partial, or fail verdict, and a fail can chain into an auto-fix run.
## Domains
Deployed apps ship to one of two places:
| Option | URL | Availability |
| ------------------------- | ---------------------------------------------- | ---------------------------------------- |
| Branded draft preview | ProductOS preview URL | Hobby |
| Production web deployment | Custom domain, production hosting, and backend | Builder, Founder, team, and agency plans |
Hobby supports draft exploration rather than production operation. Paid plans with active-product capacity can deploy a production web product with a custom domain and backend. Mobile and desktop release operations are separate channels in most plans. See [Products, channels and billing](/docs/pricing/products-channels-and-billing).
## Where this runs
All ProductOS deployments target Vercel, and your code always flows through your own GitHub repo on the way there. That means no proprietary hosting layer: if you later want to deploy the same repo yourself, through your own Vercel account or any other host, nothing stands in the way.
## Related pages
* [Deploy Agent](/docs/agents/deploy): the agent behind the deploy action
* [Sandboxes](/docs/code/sandboxes): how the development environment works
* [Security and data](/docs/platform/security-and-data): isolation and data handling
# Security and data
Source: https://productos.dev/docs/platform/security-and-data
How ProductOS handles authentication, where your data is stored, how sandboxes are isolated, and how your provider API keys are encrypted.
This page describes how ProductOS authenticates you, where your data lives, and how workloads are isolated.
## Authentication
All ProductOS surfaces share a single authentication layer, powered by Better Auth and backed by a shared Postgres database. You sign in once and your session works across `beta.productos.dev`, `develop.productos.dev`, and `design.productos.dev`: session cookies are set at the `.productos.dev` domain level, so moving between surfaces never asks you to log in again.
Supported sign-in methods:
* **Google** OAuth
* **GitHub** OAuth
* **Email and password**, with password reset emails delivered via Resend using time-limited tokens
Authenticated application routes are protected by middleware: unauthenticated requests are redirected to the login page, and public routes are explicitly allowlisted.
## Where your data lives
| Data | Storage |
| ------------------------------------------------ | ------------------------------------------------- |
| Account, sessions, provider keys | Shared auth database (Neon Postgres) |
| Projects, research, PRDs, designs, code metadata | Per-surface application databases (Neon Postgres) |
| File exports and code bundles | AWS S3 |
| Images and screenshots | Vercel Blob |
Each surface has its own application database; only identity is shared. All web surfaces run on Vercel, with Content Security Policy headers configured per surface to restrict script and resource origins, and CORS configured for legitimate cross-surface calls.
Your generated code has a home you control: it syncs to your own GitHub repository as it is written, and you can export your project in full at any time. See [Code ownership](/docs/platform/code-ownership).
## Sandbox isolation
AI-generated code never runs on your machine or on shared platform hosts. Each project runs in an isolated cloud sandbox (powered by Blaxel) that provides a live preview URL without exposing the host environment.
The sandbox lifecycle is contained end to end:
1. A sandbox is created or resumed for your project
2. Agents write files, install dependencies, and run builds inside it
3. A preview URL is returned for the embedded preview
4. Generated code is persisted to your project
5. The sandbox is cleaned up after an inactivity timeout
Sandboxes are project-scoped: one sandbox per active project session, so projects cannot see each other's environments.
## API key encryption (BYOK)
If you [bring your own provider keys](/docs/platform/byok-and-models), they are stored AES-256-GCM encrypted in the shared account database. The raw key is never returned to the client after you save it; the UI shows only the last four characters. Keys work across all surfaces without being re-entered.
## Billing data
Payments are processed by Polar, a dedicated payment processor; ProductOS does not handle your card details directly. AI capacity is recorded through a workspace credit ledger so customers and administrators can understand usage without surprise overages. See [AI credits and models](/docs/pricing/ai-credits-and-models).
## Questions
If you have a security question or want to report an issue, contact [enterprise@productos.dev](mailto:enterprise@productos.dev).
# Agencies
Source: https://productos.dev/docs/pricing/agencies
Studio, Scale, and Enterprise plans for agencies: client products, branded and white-label rights, credit pools, and add-ons.
Agency plans cover studios and delivery organizations that build products for clients. You pay for the client products you operate, the User Licenses your staff need, and the AI capacity they consume. Review Licenses are free because they cannot run agents or perform productive work.
## Plan comparison
| | Studio | Scale | Enterprise |
| -------------------------- | --------------------------------------- | ------------------------------------------ | ----------------------------- |
| **Monthly price** | \$599 | \$1,499 | Custom |
| **Annual price** | \$5,990 (billed as \$499/mo equivalent) | \$14,990 (billed as \$1,249/mo equivalent) | Custom |
| **Active client products** | 10 | 40 | Custom |
| **AI credits** | 12,000 pooled / month | 35,000 pooled / month | Custom |
| **Model access** | Advanced + Frontier | Full Frontier access | Private + multi-brand catalog |
| **Agent concurrency** | 8 | 25 | Custom |
| **User Licenses** | 5 | 15 | Custom |
| **Client review access** | Unlimited, review-only | Unlimited, review-only | Unlimited, review-only |
| **Branding** | ProductOS-branded | White-label | White-label |
| **Add-on User License** | \$79/mo | \$69/mo | Custom |
| **Add-on product** | \$39/mo | \$29/mo | Custom |
## Studio
\$599 per month, or \$**5,990 billed annually (displayed as \$499 per month).**
Studio is for boutique agencies and product studios delivering up to 10 active client products. It gives you ProductOS-branded client previews and reports, separate AI budgets per client product, and enough capacity for a small delivery team.
### What is included
* 10 active client products
* 12,000 pooled AI credits per month
* Advanced and Frontier model access
* 8 concurrent agents
* 5 User Licenses
* Unlimited Review Licenses for clients (view and approve only)
* ProductOS-branded client previews and reports
* Separate AI budgets for every client product
* Client approvals and per-client usage controls
* Standard build concurrency
### What is not included
Studio does not include white-label delivery. Client previews, reports, and the client portal carry ProductOS branding. If you need to deliver under your own brand, upgrade to Scale.
### Add-ons
| Add-on | Price |
| -------------------------------- | ------------ |
| Additional User License | \$79 / month |
| Additional active client product | \$39 / month |
### Who it is for
Studio fits boutique agencies building products for clients while ProductOS handles the AI-powered workflow. Clients receive Review Licenses without consuming a paid User or Collaborator License; identity is still required so approvals remain attributable and auditable.
### Switching to Scale
Scale adds white-label previews, reports, and the client portal. It also adds client-level AI credit pools with margin controls, agency-controlled top-ups, priority build concurrency, and 40 active client products. If you are delivering for clients who expect a branded experience, or you need to scale beyond 10 active client products, Scale is the upgrade.
***
## Scale
\$1,499 per month, or \$**14,990 billed annually (displayed as \$1,249 per month).**
Scale is for established agencies that are scaling white-label delivery across a growing client portfolio. It includes full white-label rights, 40 client products, 35,000 credits, and priority build concurrency.
### What is included
* 40 active client products
* 35,000 pooled AI credits per month
* Full Frontier model access
* 25 concurrent agents
* 15 User Licenses
* Unlimited review-only client access
* White-label previews, reports, and client portal
* Advanced permissions and audit logs
* Priority build concurrency
* Client-level AI credit pools and margin controls
* Agency-controlled top-ups
* Premium image and video models
* Dedicated onboarding and support
* Discounted Production Handoff engagements
### What white-label covers
White-label on Scale includes:
* Client previews under your branding
* Reports under your branding
* Client portal under your branding
White-label means the agency delivers under its own brand identity. The client portal, reports, and preview URLs carry the agency branding, not ProductOS branding.
### Add-ons
| Add-on | Price |
| -------------------------------- | ------------ |
| Additional User License | \$69 / month |
| Additional active client product | \$29 / month |
### Who it is for
Scale fits agencies that are delivering production products for multiple clients and need to present a consistent brand to each one. The client credit pools and margin controls also make it practical to pass AI costs through to clients as part of a project fee, rather than absorbing them as platform overhead.
### Switching to Enterprise
Enterprise adds custom staff and product volume, multi-brand white-label controls, SSO and SCIM, multi-brand model policies and allowlists, dedicated private model routing, private infrastructure, SLA and compliance support, and custom Production Handoff terms. Contact [enterprise@productos.dev](mailto:enterprise@productos.dev) to discuss custom terms.
***
## Enterprise
**Custom pricing, scoped to your requirements.**
Enterprise covers multi-brand agency groups and global delivery organizations that need custom controls, infrastructure, and compliance support.
### What is included
* Custom active client product volume
* Custom committed AI capacity
* Custom concurrency
* Private and multi-brand model catalog
* Custom staff and product volume
* Multi-brand white-label controls
* SSO and SCIM
* Multi-brand model policies and allowlists
* Dedicated private model routing
* Private infrastructure
* SLA and compliance support
* Custom Production Handoff terms
### Who it is for
Enterprise is for agencies that are operating as the product delivery platform for their clients and need custom volume, multi-brand controls, or private infrastructure to support that. Contact [enterprise@productos.dev](mailto:enterprise@productos.dev) to scope a plan.
***
## Credit pooling and client budgets
AI credits pool at the workspace level on agency plans. Admins can then set separate budgets for every client product, approve top-ups per client, and decide which products may use Frontier models.
Agency-controlled top-ups on Scale and Enterprise allow the agency to purchase additional credits and allocate them to specific client products without requiring client involvement.
Review Licenses do not consume AI capacity because reviewers cannot run agents.
***
## Annual billing
Annual billing for Studio is \$5,990, priced at 10 months and billed once annually. The displayed equivalent is \$499 per month.
Annual billing for Scale is \$14,990, priced at 10 months and billed once annually. The displayed equivalent is \$1,249 per month.
Annual billing simplifies client quoting and includes two months compared with paying monthly for a full year.
***
## Handoff and transfer
Agencies can hand off client products to the client at any time. Ownership, billing, and administration transfer without rebuilding the project. The client continues on their own ProductOS plan, and the agency retains access only if the client invites it back.
For clients who want to fully detach from ProductOS, Production Handoff packages the code, environment, and history for independent hosting, with optional ongoing care afterward. Scale and Enterprise include discounted Production Handoff rates.
***
## Related pages
* [Pricing overview](/docs/pricing/overview): how the three commercial units fit together
* [Individuals](/docs/pricing/individuals): for solo builder plans
* [Teams](/docs/pricing/teams): for internal team plans
* [AI credits and models](/docs/pricing/ai-credits-and-models): credit pooling, budgets, and top-ups
* [Licenses and access](/docs/pricing/licenses-and-access): role definitions and capability matrix
* [Products, channels and billing](/docs/pricing/products-channels-and-billing): product lifecycle, channel add-ons, and billing mechanics
* [Implementation reference](/docs/pricing/implementation-reference): developer-oriented commercial contract
# AI credits and models
Source: https://productos.dev/docs/pricing/ai-credits-and-models
How AI credits work as included capacity and cost control: exact allowances, pooling, budgets, top-ups, exhaustion, and model tier gates.
AI credits are the capacity unit for every AI generation across ProductOS. Each plan includes a monthly allowance, so credits act as capacity and cost control rather than a per-prompt invoice.
## How credits work
Every call to a model consumes credits. More capable models, longer context, multimodal inputs, and more complex tasks generally consume more credits. ProductOS shows an estimated credit cost before an expensive action; the final credit cost follows the active model and task rate.
Credits are included capacity and a cost-control mechanism. The primary commercial unit is the product you operate, not the AI calls you make within it. You still pay for your plan regardless of how heavily you use the AI.
## Included credits by plan
### Individuals
| Plan | Monthly credits |
| ------- | --------------- |
| Hobby | 100 |
| Builder | 750 |
| Founder | 2,000 |
### Teams
| Plan | Monthly credits |
| ---------- | ------------------------- |
| Startup | 8,000 pooled |
| Business | 25,000 pooled |
| Enterprise | Custom committed capacity |
### Agencies
| Plan | Monthly credits |
| ---------- | ------------------------- |
| Studio | 12,000 pooled |
| Scale | 35,000 pooled |
| Enterprise | Custom committed capacity |
## Credit measurement
Credit consumption varies by model and by task complexity. A call to a fast, lightweight model consumes far fewer credits than a call to a top-tier reasoning model. Multimodal calls (text plus image generation or understanding) consume more credits than text-only calls.
ProductOS provides a cost preview before you commit to an action. The preview shows the estimated credit cost based on the current model and task type.
## Pooling
On individual plans, credits belong to the individual and do not pool with anyone else.
On team and agency plans, credits pool at the workspace level. All members draw from the same pool. Admins can set budgets by product, department, member, or client to distribute capacity across the organization.
Review licenses do not consume AI capacity because they cannot run agents.
## Budgets and limits
Team and agency admins can set AI budgets at multiple levels:
* **Product budget**: limit AI usage for a specific product
* **Member budget**: limit AI usage for a specific named member
* **Department budget**: limit AI usage for a group of members
* **Client budget**: (agencies only) limit AI usage for a specific client product
Budgets are configurable by admins and do not require a plan change. When a budget is exhausted, the relevant product or member cannot run new AI builds until an admin approves a top-up.
## Top-ups
When included credits are exhausted, new AI builds pause until the allowance renews or an admin approves a top-up. Top-ups are approved by an admin, not automatic, so there are no surprise charges.
On team plans, only admins can purchase top-ups. On agency plans, agencies can purchase top-ups and allocate them to specific client products.
Top-up pricing is not published in these docs because it varies by plan and volume. Contact [hello@productos.dev](mailto:hello@productos.dev) for current top-up pricing.
## Rollover
Paid-plan included credits roll over for one billing cycle. Hobby credits do not roll over.
For example, if a Business workspace has 25,000 monthly credits and uses 20,000 in January, the remaining 5,000 carries into February. Rollover is capped at one cycle; it does not accumulate indefinitely.
Purchased top-up credits follow the terms shown at purchase.
## Exhaustion behavior
When AI credits run out, new AI builds pause. Products already running in production remain available. You are notified as you approach your limit.
The exhaustion behavior is the same across all plans: no new AI builds start until the allowance renews or a top-up is approved. There is no automatic overage billing.
## Model tiers
ProductOS offers three model tiers. Which tiers are available to you depends on your plan.
### Essential
Essential models handle ideation, classification, summaries, and routine edits at low credit cost. These models are fast and efficient for routine work.
Included in: Hobby, Builder
### Advanced
Advanced models handle stronger reasoning, coding, multimodal design, and long-context product work. They consume more credits than Essential models.
Included in: Builder, Founder, Startup, Business, Studio, Scale
### Frontier
Frontier models handle architecture decisions, high-fidelity design, difficult coding, and final review. These are the most capable models available and consume the most credits.
Included in: Founder (with Auto Router), Startup, Business, Studio, Scale, Enterprise
On Builder, Frontier model access is available through qualifying top-ups.
## Auto Router
The ProductOS Auto Router selects the right model for each task by balancing reasoning quality, speed, multimodality, and cost. It routes research, strategy, design, coding, QA, and operations independently, choosing Essential, Advanced, or Frontier depending on the task demands and your plan entitlements.
On Founder, Startup, Business, and Scale plans, the Auto Router is included. Builder can add Frontier model access through qualifying top-ups.
Manual model selection remains available where the plan and workspace policy allow it. Admins can also configure model allowlists to restrict which tiers specific teams, products, or stages may use.
## Bring Your Own Key (BYOK) and Bring Your Own Model (BYOM)
Team Enterprise and Agency Enterprise support Bring Your Own Key and Bring Your Own Model. Runs routed through approved customer-supplied credentials do not draw from the ProductOS included-credit pool. Usage remains logged so the workspace history stays complete.
This is useful for organizations that have existing provider commitments or need to route specific workloads through their own accounts.
See [BYOK and models](/docs/platform/byok-and-models) for the full detail on connecting your own keys.
## Related pages
* [Pricing overview](/docs/pricing/overview): how credits fit into the overall pricing model
* [Individuals](/docs/pricing/individuals): credit allowances for Hobby, Builder, Founder
* [Teams](/docs/pricing/teams): credit allowances for Startup, Business, Enterprise
* [Agencies](/docs/pricing/agencies): credit allowances for Studio, Scale, Enterprise
* [Licenses and access](/docs/pricing/licenses-and-access): how Review licenses avoid consuming AI capacity
* [Products, channels and billing](/docs/pricing/products-channels-and-billing): how products relate to AI capacity
* [Implementation reference](/docs/pricing/implementation-reference): credit ledger behavior for developers
# Implementation reference
Source: https://productos.dev/docs/pricing/implementation-reference
Commercial implementation contract for developers: canonical entities, entitlement fields, plan matrix, billing events, credit ledger behavior, and acceptance checklist.
This page translates the approved commercial model into a target implementation contract for developers building ProductOS billing and entitlements. It defines normalized entities, entitlement fields, plan invariants, billing events, and acceptance criteria.
This is a target contract, not a claim that every field or workflow already exists in production. Map these concepts to the current application schema, preserve existing customer data, and verify migrations against the live billing provider before rollout. Customer-facing availability is governed by the live [pricing page](https://productos.dev/pricing) and executed order terms.
Code blocks on this page are implementation-neutral pseudocode. Names such as `Workspace`, `License`, and `CreditEvent` describe required commercial behavior; they do not prescribe database table names.
## Canonical entities
### Workspace
The workspace is the top-level billing and administrative container. All plans, products, licenses, and credits belong to a workspace.
```text theme={null}
Workspace {
id: string
plan: PlanKey
billingCycle: 'monthly' | 'annual'
createdAt: timestamp
}
```
### Plan
A plan defines the commercial terms for a workspace. Plans are identified by a `PlanKey`.
```text theme={null}
PlanKey =
| 'hobby'
| 'builder'
| 'founder'
| 'startup'
| 'business'
| 'enterprise'
| 'studio'
| 'scale'
| 'agency_enterprise'
```
### Product
A product is a digital experience operated for end users. A product is `active` once it has a live domain, backend, or app store release. A product that is in development but not yet released is a `draft`.
```text theme={null}
Product {
id: string
workspaceId: string
name: string
status: 'draft' | 'active' | 'archived'
lineage: string (immutable identifier surviving fork/clone/transfer)
createdAt: timestamp
activatedAt: timestamp | null
archivedAt: timestamp | null
}
```
A product becomes active when `activatedAt` is set. A product that is archived has `archivedAt` set and its slot is freed for a new product.
### License
A license is a named entitlement tied to one human identity.
```text theme={null}
License {
id: string
workspaceId: string
userId: string
role: 'user' | 'collaborator' | 'review'
status: 'active' | 'released' | 'reassigned'
assignedAt: timestamp
releasedAt: timestamp | null
reassignedTo: string | null
}
```
A license cannot be shared. `userId` must reference a single human identity. The implementation must deter shared-login exploitation through identity, device, concurrency, and audit controls.
### AI Credit Ledger
The credit ledger records consumption, allocation, rollover, and top-up events.
```text theme={null}
CreditEvent {
id: string
workspaceId: string
type: 'allocation' | 'consumption' | 'rollover' | 'topup' | 'expiry'
amount: number (positive for allocation/rollover/topup, negative for consumption/expiry)
balanceAfter: number
productId: string | null
userId: string | null
timestamp: timestamp
}
```
The current balance is derived from the immutable events for the workspace. Production implementations must scope the calculation to non-expired credit lots or maintain a transactionally updated balance projection. Do not sum historical allocations after their expiry window.
## Entitlement fields
The canonical source of truth for workspace entitlements is the workspace record. Do not compute entitlements from plan metadata at the client side; always query the server-side workspace record.
### Per-plan entitlement matrix
| Field | Hobby | Builder | Founder | Startup | Business | Enterprise | Studio | Scale | Agency Enterprise |
| ------------------- | -------------- | ------------------- | ------------------ | ------------------ | --------- | ---------------- | ------------------ | --------- | ----------------- |
| `maxActiveProducts` | 0 (draft only) | 1 | 3 | 5 | 20 | 40+ | 10 | 40 | Custom |
| `monthlyCredits` | 100 | 750 | 2,000 | 8,000 | 25,000 | Custom | 12,000 | 35,000 | Custom |
| `creditsPool` | false | false | false | true | true | true | true | true | true |
| `creditsRollover` | false | 1 cycle | 1 cycle | 1 cycle | 1 cycle | Custom | 1 cycle | 1 cycle | Custom |
| `maxAgents` | 1 | 2 | 3 | 5 | 15 | Custom | 8 | 25 | Custom |
| `modelTier` | essential | essential\_advanced | advanced\_frontier | advanced\_frontier | frontier | private\_catalog | advanced\_frontier | frontier | private\_catalog |
| `autoRouter` | false | topup\_required | true | true | true | custom | false | true | custom |
| `channelWeb` | preview\_only | true | true | true | true | true | true | true | custom |
| `channelMobile` | false | false | 1 included | add-on | add-on | add-on | add-on | add-on | add-on |
| `channelDesktop` | false | false | false | add-on | add-on | add-on | add-on | add-on | add-on |
| `maxNamedMembers` | 1 | 1 | 1 | 5 | 25 | 50+ | 5 | 15 | Custom |
| `maxUsers` | 1 | 1 | 1 | 3 | 10 | Custom | 5 | 15 | Custom |
| `maxCollaborators` | 0 | 0 | 0 | 2 | 15 | Custom | 0 | 0 | Custom |
| `maxReviewers` | 0 | 0 | 3 | unlimited | unlimited | unlimited | unlimited | unlimited | unlimited |
| `whiteLabel` | false | false | false | false | false | true | false | true | true |
| `byok` | false | false | false | false | false | true | false | false | true |
| `sso` | false | false | false | false | false | true | false | false | true |
| `scim` | false | false | false | false | false | true | false | false | true |
### Active product count
The number of active products is the count of products in the workspace where `status = 'active'`. Draft products do not count. Archived products do not count.
```text theme={null}
activeProductCount(workspaceId) = COUNT(Product WHERE workspaceId = workspaceId AND status = 'active')
```
When `activeProductCount` exceeds `maxActiveProducts`, no new products can be activated. Existing active products are not affected.
### Credit consumption
Credit consumption is measured per model call. The credit cost depends on the active model tier, task type, context, and modality according to the server-side rate card. Exact rates are internal and may change as provider pricing and routing evolve.
The credit ledger is debited on call completion, not on call start. If a call fails, no credits are consumed.
```text theme={null}
consumeCredits(workspaceId, amount, productId?, userId?) {
balance = getBalance(workspaceId)
if (balance < amount) return INSUFFICIENT_CREDITS
insert CreditEvent {
type: 'consumption',
amount: -amount,
balanceAfter: balance - amount,
productId,
userId,
}
}
```
### Credit exhaustion
When the credit balance reaches zero:
1. New AI build requests return `INSUFFICIENT_CREDITS`.
2. Existing in-progress builds continue to completion.
3. Products already running in production are not affected.
4. Admins receive a notification.
5. Admins can approve a top-up.
### Credit rollover
On paid plans, at the end of each billing cycle, the remaining included-credit balance rolls into the next cycle up to a maximum of one cycle's allocation. Hobby credits expire at renewal. Enterprise rollover behavior is contractual.
```text theme={null}
rollover(workspaceId) {
includedBalance = getUnspentIncludedBalance(workspaceId)
allocation = getMonthlyAllocation(workspaceId)
rolloverAmount = min(includedBalance, allocation)
expireCurrentIncludedCreditLots(workspaceId)
insert CreditEvent { type: 'rollover', amount: rolloverAmount }
insert CreditEvent { type: 'allocation', amount: allocation }
}
```
Top-up lots follow their purchase terms and are not expired by the included-credit rollover job.
## Annual billing formula
Annual billing is priced at 10 times the monthly price and charged once per year. The displayed monthly equivalent is rounded to the nearest dollar.
```text theme={null}
annualTotal = monthlyPrice * 10
displayedMonthly = Math.round(monthlyPrice * 10 / 12)
```
The actual billing event charges `annualTotal`. The displayed figure is for marketing purposes only.
## License enforcement
When a license is assigned to a user, the platform records `userId` on the license. All API calls and UI actions are checked against the user's license role.
```text theme={null}
checkAccess(workspaceId, userId, action) {
license = getActiveLicense(workspaceId, userId)
if (!license) return DENIED
capability = CAPABILITY_MAP[license.role][action]
return capability ? ALLOWED : DENIED
}
```
A user with no license, or a license with an insufficient role, cannot perform actions beyond their capability. This check happens server-side on every request.
### Reassignment
Reassignment is logged as a `reassigned` event on the old license and a new `assigned` event on the new license. There is a cooldown between reassignments on the same license slot.
Concurrent reassignments are prevented by a lock on the license record during the reassignment transaction.
## Concurrency enforcement
Concurrency limits how many agents can run simultaneously for a workspace.
```text theme={null}
checkConcurrency(workspaceId) {
activeCount = countRunningAgents(workspaceId)
maxConcurrency = getMaxConcurrency(workspaceId)
if (activeCount >= maxConcurrency) {
return CONCURRENCY_EXCEEDED
}
return ALLOWED
}
```
The concurrency limit applies across all products and all users in a workspace. It is not a per-user or per-product limit.
## Channel entitlements
Channel entitlements are checked against the workspace plan and the product configuration.
```text theme={null}
checkChannel(workspaceId, productId, channel) {
plan = getPlan(workspaceId)
if (channel === 'web') return plan.channelWeb === true ? ALLOWED : PREVIEW_ONLY
if (channel === 'mobile') {
included = hasRemainingIncludedChannel(workspaceId, productId, 'mobile')
addOn = productHasAddOn(productId, 'mobile')
return included || addOn ? ALLOWED : CHANNEL_NOT_INCLUDED
}
if (channel === 'desktop') {
addOn = productHasAddOn(productId, 'desktop')
return addOn ? ALLOWED : CHANNEL_NOT_INCLUDED
}
}
```
## Agency white-label gates
White-label is a workspace-level entitlement. When `whiteLabel = true`, the workspace can serve client-facing surfaces (previews, reports, client portal) under the agency's branding.
```text theme={null}
checkWhiteLabel(workspaceId) {
plan = getPlan(workspaceId)
return plan.whiteLabel === true
}
```
White-label does not affect the billing relationship between the agency and ProductOS. It only controls whether the agency's branding appears on client-facing surfaces.
## Product lifecycle events
| Event | Trigger | Billing effect |
| ------------------- | -------------------------------- | --------------------------------------------------------------- |
| Product activated | `activatedAt` set for first time | Product counts toward `maxActiveProducts` |
| Product archived | `archivedAt` set | Product no longer counts toward `maxActiveProducts` |
| Product reactivated | `archivedAt` cleared | Product counts toward `maxActiveProducts` |
| Product transferred | `workspaceId` changes | Source workspace product count decreases; destination increases |
| Product cloned | New product created from lineage | New product starts as draft; activation counts when released |
## Lineage
Lineage is an immutable identifier assigned to a product at creation. It survives fork, clone, new repository, new domain, and workspace transfer. Lineage is used to prevent duplicate billing when a product is reconstructed from its history.
```text theme={null}
getLineage(productId) = Product[productId].lineage
```
The lineage cannot be changed after product creation. Two products with the same lineage are the same product history; only one can be active at a time within a workspace.
## Migration and versioning
When a workspace changes plans:
1. Preserve product history, identities, audit events, and the credit ledger.
2. Apply the effective date and any proration or true-up shown at checkout or defined in the executed order.
3. Do not silently archive products or remove a live entitlement.
4. Before a downgrade, validate product, license, channel, and concurrency usage against the destination plan. Require remediation or an alternative plan when the workspace exceeds the destination allowance.
5. Record both the previous and resulting entitlement snapshots for billing support and rollback.
Do not invent credit forfeiture or grandfathering behavior in the client. The billing service must return the effective credit balance and expiry schedule after the plan change.
## Analytics and audit
The following events are required to be logged and queryable:
* `license.assigned`: userId, role, timestamp
* `license.released`: userId, role, timestamp
* `license.reassigned`: fromUserId, toUserId, role, timestamp
* `product.activated`: productId, timestamp
* `product.archived`: productId, timestamp
* `product.transferred`: productId, fromWorkspaceId, toWorkspaceId, timestamp
* `credit.consumption`: workspaceId, amount, productId, userId, timestamp
* `credit.topup`: workspaceId, amount, adminUserId, timestamp
* `credit.rollover`: workspaceId, amount, timestamp
* `credit.expiry`: workspaceId, amount, timestamp
* `billing.cycle`: workspaceId, amount, cycleStart, cycleEnd, timestamp
These logs are required for billing reconciliation, compliance auditing, and debugging entitlement issues.
## Implementation acceptance checklist
Before shipping a billing or entitlement feature, verify:
* [ ] Credit deduction is recorded atomically with the call completion, not on start
* [ ] Insufficient credit returns `INSUFFICIENT_CREDITS` and does not silently allow overage (unless overage is explicitly configured)
* [ ] Product activation is gated against `maxActiveProducts` and returns a clear error
* [ ] Archive frees the product slot immediately
* [ ] Reactivation reclaims the slot
* [ ] License role checks happen server-side on every action
* [ ] Concurrent reassignments are prevented by database-level locking
* [ ] Concurrency limit is enforced across all products and users in a workspace
* [ ] Annual billing charges exactly 10 times the monthly price at renewal
* [ ] Displayed monthly equivalent is `Math.round(monthly * 10 / 12)`
* [ ] Paid license additions are prorated for the remaining term, charged immediately on monthly billing and recorded for annual true-up on annual billing
* [ ] Paid license removals take effect at renewal
* [ ] Channel add-ons are per-product, not per-workspace
* [ ] White-label check is workspace-level, not per-product
* [ ] All billing events are logged with timestamp, amount, and actor
* [ ] Paid-plan included-credit rollover clears expired credits and rolls over no more than one cycle's allocation
* [ ] Lineage is immutable and preserved across fork, clone, transfer, and new repository
* [ ] No new pricing page or nav description contains stale plan names or numbers
# Individuals
Source: https://productos.dev/docs/pricing/individuals
Hobby, Builder, and Founder plans: exact prices, AI credits, model access, concurrency, product capacity, and upgrade paths.
Individual plans cover solo makers, indie developers, and founders who are building on their own. You pay for the products you operate and nothing else.
## Plan comparison
| | Hobby | Builder | Founder |
| --------------------- | ---------------- | ------------------------------------ | ------------------------------------ |
| **Monthly price** | Free | \$29 | \$79 |
| **Annual price** | Free | \$290 (billed as \$24/mo equivalent) | \$790 (billed as \$66/mo equivalent) |
| **Active products** | 1 personal draft | 1 active product | 3 active products |
| **AI credits** | 100 / month | 750 / month | 2,000 / month |
| **Model access** | Essential | Essential + Advanced | Advanced + Frontier |
| **Agent concurrency** | 1 agent | 2 concurrent agents | 3 concurrent agents |
| **Mobile channel** | | | Included (1) |
| **Auto Router** | | Available with top-ups | Included |
## Hobby
**\$0 per month.**
Hobby is for curious makers, students, and anyone exploring ProductOS before committing to a paid plan. It provides the full ProductOS pipeline in a branded draft preview.
### What is included
* 1 personal draft product
* 100 AI credits per month
* Essential model access
* 1 active agent
* Full pipeline preview (Design, Develop, Build)
* Limited image and multimodal generation
* ProductOS branding on the preview
### What is not included
Hobby does not include production deploy, custom domains, Frontier model access, or the ability to operate more than one personal draft. When you are ready to ship, you upgrade to Builder or Founder.
### Switching to a paid plan
An upgrade must preserve product history, design systems, and code. The checkout flow shows the effective date and any billing adjustment before confirmation.
***
## Builder
\$29 per month, or \$**290 billed annually (displayed as \$24 per month).**
Builder is for solo builders, indie developers, and consultants shipping one production product. It gives you one User License, production deploy, and enough AI capacity for ongoing iteration.
### What is included
* 1 active product
* 750 AI credits per month
* Essential and Advanced model access
* 2 concurrent agents
* 1 User License
* Production deploy with custom domain and backend
* Private GitHub sync
* Standard image and multimodal models
* Frontier models available with top-ups
### Who it is for
Builder is the natural next step when you have validated an idea and are ready to put it in front of users. You get production infrastructure, your own domain, and enough AI capacity to iterate without watching the credit counter constantly.
### Switching to Founder
Founder adds two more active products, a larger credit pool, Frontier model access, the Auto Router, and one mobile release channel. If you are starting to operate a portfolio or want access to the strongest models without managing top-ups, upgrade to Founder.
***
## Founder
\$79 per month, or \$**790 billed annually (displayed as \$66 per month).**
Founder is for founders and serial makers operating a growing portfolio of products. It includes three active products, Frontier model access, the Auto Router, and one mobile release channel.
### What is included
* 3 active products
* 2,000 AI credits per month
* Advanced and Frontier model access
* 3 concurrent agents
* 1 User License
* Shared design systems across all three products
* ProductOS Auto Router included
* One mobile release channel (iOS and Android release operations as one channel)
* Premium image models
* AI credits shared across the founder's products
* Up to 3 free Review licenses
### Who it is for
Founder fits founders who are running more than one product in parallel and want the strongest models and automatic routing without managing individual top-ups. It also covers the mobile channel for founders who are building both a web and mobile presence.
### Annual billing
Annual billing for Founder is \$790 per year, priced at 10 months and billed once annually. The displayed equivalent is \$66 per month. The annual charge is \$790.
### Upgrade path
If you need more than three active products, more User Licenses, or agency-style client delivery, the natural next step is a team or agency plan. Contact [hello@productos.dev](mailto:hello@productos.dev) to discuss the transition.
***
## Switching between individual plans
Plan changes must preserve product data and show the effective date before confirmation. A downgrade cannot silently archive products or remove a live entitlement. If the destination plan has fewer product slots, archive products or select another plan before the change can take effect.
***
## Credit and concurrency details
Individual plans have one User License, so their included credit pool is used by that workspace owner across eligible products. Paid-plan included credits roll over for one billing cycle; Hobby credits do not. When credits run out, new AI builds pause until the next renewal, an approved top-up, or a plan upgrade.
Concurrency limits how many agents can run simultaneously. Hobby allows 1 agent. Builder allows 2 concurrent agents. Founder allows 3 concurrent agents. You cannot exceed the concurrency limit by purchasing additional credits; additional concurrency requires a plan upgrade.
***
## Related pages
* [Pricing overview](/docs/pricing/overview): how the three commercial units fit together
* [AI credits and models](/docs/pricing/ai-credits-and-models): how credits are measured, pooling behavior, and model tier gates
* [Licenses and access](/docs/pricing/licenses-and-access): User, Collaborator, and Review License details
* [Products, channels and billing](/docs/pricing/products-channels-and-billing): product definition, channel add-ons, and billing mechanics
* [Teams](/docs/pricing/teams): if you are adding teammates
* [Agencies](/docs/pricing/agencies): if you are delivering for clients
# Licenses and access
Source: https://productos.dev/docs/pricing/licenses-and-access
User, Collaborator, and Review Licenses: capability matrix, named-user policy, reassignment, SSO, SCIM, and concurrency controls.
Every ProductOS license is named and tied to one human identity. Licenses cannot be shared across multiple people, and credentials cannot be swapped between accounts. This keeps activity, approvals, and usage attributable to a person.
## The three license types
### User License
User Licenses unlock the full ProductOS pipeline. A User License holder can:
* View, comment on, and approve invited products
* Edit planning docs, requirements, backlog items, and design feedback
* Use AI for planning and design feedback
* Edit source code, PRDs, and design systems
* Run build agents and consume build capacity
* Create new products
* Deploy to production
* Export or self-host
* Connect GitHub
### Collaborator License
Collaborator Licenses cover everyone who needs to contribute to planning and design but does not need to build or deploy. A Collaborator can:
* View, comment on, and approve invited products
* Edit planning docs, requirements, backlog items, and design feedback
* Use AI for planning and design feedback
A Collaborator cannot run agents, edit source code, deploy, or create products.
### Review License
Review Licenses are for stakeholders who need visibility into product progress without productive access. A reviewer can:
* View, comment on, and approve invited products
Review Licenses do not consume AI capacity. Reviewers cannot run agents, edit artifacts, or access source code.
## Capability matrix
| Capability | User License | Collaborator License | Review License |
| ---------------------------------------------------------- | ------------ | -------------------- | -------------- |
| View, comment, and approve invited products | Yes | Yes | Yes |
| Edit planning docs, requirements, backlog, design feedback | Yes | Yes | No |
| Use AI for planning and design feedback | Yes | Yes | No |
| Edit source code, PRDs, design systems | Yes | No | No |
| Run build agents and consume build capacity | Yes | No | No |
| Create new products | Yes | No | No |
| Deploy to production | Yes | No | No |
| Export or self-host | Yes | No | No |
| Connect GitHub | Yes | No | No |
| Consume AI credits | Yes | Yes | No |
## Named-user policy
Each license is tied to a specific human being. You cannot:
* Share login credentials across multiple people
* Log in as someone else or let someone else log in as you
* Assign one license to multiple people or rotate it between people without reassignment
The product must enforce this named-user policy through identity, device, concurrency, and audit controls. Enforcement should stop shared-login exploitation without disrupting legitimate multi-device use.
## Reassignment
When a team member leaves or changes roles, an admin can reassign the license. Reassignment must be auditable, with a reasonable cooldown to prevent rotating one paid license among multiple people.
A paid license released mid-term stays available for reassignment for the remainder of that term. You do not lose the value of the paid term when you release it early.
## License billing
Adding a User or Collaborator License creates a prorated obligation for the rest of the current term. Monthly workspaces charge it immediately. Annual workspaces record it for the annual true-up.
Removing a license takes effect at your next renewal. The team keeps access through the end of what you already paid for.
## Individual plan licenses
Individual plans include one User License. Founder includes up to 3 free Review Licenses for stakeholders who need to see product progress without building.
Individual plans do not include additional User or Collaborator Licenses. To add more people, upgrade to a team or agency plan.
## Team and agency licenses
Team and agency plans define a starting license mix and allow add-ons:
**Startup**: 5 named members (3 User Licenses, 2 Collaborator Licenses, unlimited Review Licenses)
* Additional User License: \$59 / month
* Additional Collaborator License: \$15 / month
**Business**: 25 named members (10 User Licenses, 15 Collaborator Licenses, unlimited Review Licenses)
* Additional User License: \$55 / month
* Additional Collaborator License: \$12 / month
**Studio**: 5 User Licenses, unlimited Review Licenses
* Additional User License: \$79 / month
**Scale**: 15 User Licenses, unlimited Review Licenses
* Additional User License: \$69 / month
Enterprise plans define a custom license mix and volume.
## Enterprise provisioning: SSO and SCIM
On Enterprise plans, you can automate license provisioning and deprovisioning using your identity provider:
**SAML or OIDC SSO** lets your team sign in with your existing identity provider. You control who has access through your identity provider rather than managing ProductOS credentials separately.
**SCIM** (System for Cross-domain Identity Management) automates provisioning and deprovisioning. When someone joins the team, SCIM creates their ProductOS license assignment automatically. When someone leaves, SCIM deprovisions their access. This keeps the licensed-user count in sync with your organization without manual updates.
SSO and SCIM are available on Enterprise plans. Contact [enterprise@productos.dev](mailto:enterprise@productos.dev) to discuss setup.
## Concurrent device limits
ProductOS enforces a reasonable concurrent device limit per named license. This prevents credential sharing without interfering with legitimate multi-device use. The specific limit depends on the plan and is enforced at the platform level.
## Related pages
* [Pricing overview](/docs/pricing/overview): how licenses fit into the overall pricing model
* [Individuals](/docs/pricing/individuals): individual plan license details
* [Teams](/docs/pricing/teams): team license details and add-on pricing
* [Agencies](/docs/pricing/agencies): agency license details and add-on pricing
* [Products, channels and billing](/docs/pricing/products-channels-and-billing): how license changes affect billing
* [Implementation reference](/docs/pricing/implementation-reference): developer reference for license enforcement and entitlement fields
# Pricing overview
Source: https://productos.dev/docs/pricing/overview
How ProductOS pricing works: the model, audience segments, commercial units, how to choose a plan, and links to the public pricing page.
ProductOS pricing has three independent commercial dimensions. You pay for the products you operate, the people who work on them, and the AI capacity they consume. Every plan is a combination of those three dimensions, tuned for a specific audience.
This section documents the approved commercial specification that ProductOS is implementing. Public checkout and in-product entitlement availability may roll out in stages. Use the live [pricing page](https://productos.dev/pricing) or contact [hello@productos.dev](mailto:hello@productos.dev) for current purchase availability.
## The three commercial units
**Products** are the primary unit. A product becomes active once it has a live domain, backend, or app store release. Its design system, code, and history persist through forks, clones, and transfers. You choose how many products you operate and add more as you grow.
**Licenses** are named, role-based access for the humans on your team. User Licenses can build and deploy. Collaborator Licenses can review and edit planning artifacts. Review Licenses can view and approve. Each plan defines a starting mix, and you add more licenses as your team grows.
**AI credits** are included capacity and a cost-control layer, not a billing switch. Credits pool at the workspace level on team and agency plans, and you set budgets by product, member, or department. When credits run out, new AI builds pause until the allowance renews or an admin approves a top-up.
## Audience segments
| Segment | Who it is for | Starting point |
| --------------- | -------------------------------------------------------------- | -------------------------------------------------------- |
| **Individuals** | Solo makers, indie developers, founders | Hobby \$0, Builder \$29/mo, Founder \$79/mo |
| **Teams** | Startups, SaaS teams, product departments | Startup \$399/mo, Business \$1,199/mo, Enterprise custom |
| **Agencies** | Boutique studios, established agencies, delivery organizations | Studio \$599/mo, Scale \$1,499/mo, Enterprise custom |
See [Individuals](/docs/pricing/individuals), [Teams](/docs/pricing/teams), or [Agencies](/docs/pricing/agencies) for the full plan details.
## How to choose a plan
Start with the segment that fits your situation, then choose the plan within that segment based on how many products you operate and how many people need to build.
If you are exploring or learning, **Hobby** is the free entry tier.
If you are shipping one production product, **Builder** gives you the tools and AI capacity to do it properly.
If you are a founder with a portfolio, **Founder** covers three active products, Frontier model access, and one mobile release channel.
If you are a team, **Startup** is the entry point with pooled AI credits, named members, and admin controls.
If you are managing multiple products across a growing team, **Business** adds 20 products, 25,000 pooled credits, and rollover credits for one billing cycle.
If you need custom volume, SSO, SCIM, private model routing, or dedicated infrastructure, **Enterprise** is scoped to your requirements.
## AI credits and model tiers
Credits are measured per call and vary by model capability. Three tiers are available depending on your plan:
**Essential** models handle ideation, classification, summaries, and routine edits at low credit cost.
**Advanced** models handle stronger reasoning, coding, multimodal design, and long-context product work.
**Frontier** models handle architecture decisions, high-fidelity design, difficult coding, and final review. Frontier access is included on Business, Scale, and Enterprise plans, and available on lower plans through top-ups.
See [AI credits and models](/docs/pricing/ai-credits-and-models) for the full detail.
## Licenses and access
Every license is tied to one human identity. You cannot share a login or swap credentials between people. The three license types are:
**User License** can run agents, build, deploy, export, and manage active products. This is the full-access paid license.
**Collaborator License** can edit planning artifacts, requirements, backlog items, and design feedback. It cannot run agents or deploy.
**Review License** can view and approve invited products. It does not consume AI capacity.
See [Licenses and access](/docs/pricing/licenses-and-access) for the full capability matrix.
## Products, channels, and billing
A product is a live digital experience. Paid plans with active-product capacity include web production; Hobby provides a branded draft preview. Mobile and desktop are channel add-ons in most paid plans. Founder includes one mobile release channel.
Billing is monthly by default. Annual billing is priced at 10 times the monthly price and charged once annually, which includes two months compared with paying monthly for a full year. The displayed monthly equivalent is rounded to the nearest dollar.
See [Products, channels and billing](/docs/pricing/products-channels-and-billing) for the full detail.
## Current pricing status
The plans described in these docs reflect the current product-based pricing available at [productos.dev/pricing](https://productos.dev/pricing). Some features described here are actively being rolled out. See [Implementation reference](/docs/pricing/implementation-reference) for the distinction between the commercial specification and the current implementation status.
## Related pages
* [Individuals](/docs/pricing/individuals): Hobby, Builder, Founder plans in detail
* [Teams](/docs/pricing/teams): Startup, Business, Enterprise plans in detail
* [Agencies](/docs/pricing/agencies): Studio, Scale, Enterprise plans in detail
* [AI credits and models](/docs/pricing/ai-credits-and-models): credits, pooling, budgets, top-ups, model tiers
* [Licenses and access](/docs/pricing/licenses-and-access): role-based capability matrix
* [Products, channels and billing](/docs/pricing/products-channels-and-billing): product lifecycle, channels, billing mechanics
* [Implementation reference](/docs/pricing/implementation-reference): developer-oriented commercial contract
# Products, channels and billing
Source: https://productos.dev/docs/pricing/products-channels-and-billing
Active product definition, channel add-ons, monthly and annual billing, license changes, true-ups, archive and reactivation, and ProductOS operation vs Production Handoff.
ProductOS bills for the products you operate, the people who work on them, and the AI capacity they use. This page covers how products are defined, how channels relate to products, and how billing changes when you add, remove, or transfer products.
## What is an active product
A product becomes active in ProductOS once it has a live domain, backend, or app store release. Until then, it is a draft and does not count against your product allowance.
A product is a digital experience for your end users. It has a name, a design system, a codebase, a backend, and one or more delivery channels.
### Product identity and lineage
A product retains its identity and full history across:
* A fork or clone
* A new GitHub repository
* A new domain
* A transfer to another workspace
Lineage, including the history, design system, and code links, persists. This means you can restructure your repository or move a product to a different workspace without rebuilding it.
## Channels
A channel is a delivery surface for your product. The same product identity can be delivered across multiple channels, all sharing the design system, backend, context, and code.
| Channel | Description | Included in |
| --------------- | ---------------------------------------------- | ------------------------------------------- |
| Web | Custom domain, production hosting, and backend | Paid plans with an active-product allowance |
| Web preview | Draft preview with ProductOS branding | Hobby |
| Mobile | iOS and Android release operations | Add-on in most plans |
| Desktop | Desktop packaging and release operations | Add-on in most plans |
| AI intelligence | Credit pool across every ProductOS stage | Included by plan |
Paid plans include the web production channel. Hobby includes a branded draft preview but not a production deployment. Mobile and desktop are add-ons in most paid plans. Founder includes one mobile release channel.
### Channel pricing
| Channel | Price |
| -------------------------- | --------------------------- |
| Mobile release operations | +\$29 per product per month |
| Desktop release operations | +\$15 per product per month |
Channels are billed per product. If you have three active products and add a mobile channel to all three, you pay \$29 times three, or \$87 per month.
### Adding a channel
Adding a channel updates the product entitlement after checkout confirmation. Monthly workspaces charge the prorated add-on immediately; annual workspaces record the prorated obligation for the annual true-up.
### Founder mobile channel
Founder includes one mobile release channel. This means you can add mobile release operations to one product without paying the add-on fee. Additional products or additional channels are billed at the standard add-on rate.
## Monthly billing
Published self-service plans bill monthly by default. You pay for the plan and active add-ons on the workspace billing date. Enterprise terms are defined in the executed order.
## Annual billing
Annual billing is priced at 10 times the monthly price and charged once per year. You pay the full annual amount upfront and receive two months included compared with paying monthly for a full year.
The displayed monthly equivalent is rounded to the nearest dollar. The annual total is exact.
| Plan | Monthly | Annual total | Displayed equivalent |
| -------- | ------- | ------------ | -------------------- |
| Builder | \$29 | \$290 | \$24 / month |
| Founder | \$79 | \$790 | \$66 / month |
| Startup | \$399 | \$3,990 | \$333 / month |
| Business | \$1,199 | \$11,990 | \$999 / month |
| Studio | \$599 | \$5,990 | \$499 / month |
| Scale | \$1,499 | \$14,990 | \$1,249 / month |
Annual billing is available on published paid plans. Contracted mid-year additions are tracked as true-ups under the workspace's order terms.
## License additions and reductions
### Adding a license
Adding a User or Collaborator License creates a prorated obligation for the remainder of the current term. Monthly workspaces charge that addition immediately; annual workspaces record it for the annual true-up. After renewal, the license is billed for the full term.
### Removing a license
Removing a license takes effect at your next renewal. Your team keeps access through the end of what you already paid for. You do not lose the value of the paid term.
### Released licenses
A paid license released mid-term stays available for reassignment to someone else for the remainder of that term. You can reassign it without losing the billing benefit of what you already paid.
### Reassignment
Reassignment is audited. There is a reasonable cooldown between reassignments to prevent abuse. Concurrency and device controls enforce the named-user policy.
## Product additions and reductions
Published monthly add-ons for active products are:
| Plan | Additional active product |
| -------- | ------------------------- |
| Startup | \$29 / month |
| Business | \$24 / month |
| Studio | \$39 / month |
| Scale | \$29 / month |
Enterprise product volume is custom.
### Activating another product
You can activate another product while the workspace remains within its included allowance. If the allowance is full, upgrade to a plan with more active products or purchase the published add-on where available. Checkout must show the price and effective date before activation.
### Archiving a product
Archiving stops ProductOS production operation for that product and frees its active-product slot immediately while preserving its history. A lower plan price or contracted product-pack reduction takes effect according to the change shown at checkout or the executed order.
## True-ups
Annual workspaces settle contracted mid-year license or product-pack additions at renewal. The true-up covers the partial period from the addition date through the end of the annual term; the renewed subscription then includes the full annual amount.
For example, a User License added 60 days into a 365-day annual term produces a prorated obligation for the remaining 305 days, settled under the annual true-up.
## Archive and reactivation
You can archive a product at any time. Archiving frees its active-product slot while keeping its full history, design system, and code links intact. The product can be reactivated at any time without rebuilding.
Archiving is useful when a product is not currently in active operation but you want to preserve its history and be able to reactivate it later.
## ProductOS operation vs Production Handoff
ProductOS charges for operating products in production. GitHub sync, export, and fork are portability features, not billing switches. You can connect your GitHub, fork a repository, or re-import at any time without changing your bill.
When a product is fully detached from ProductOS, you have two options:
**Continue on ProductOS**: The product remains on your plan and you pay for its active-product slot.
**Production Handoff**: A separately priced engagement packages the code, environment, and history for independent hosting, with optional ongoing care afterward. This is for products that will no longer operate on ProductOS.
Scale and Enterprise include discounted Production Handoff rates. Contact [hello@productos.dev](mailto:hello@productos.dev) for Production Handoff pricing.
## Related pages
* [Pricing overview](/docs/pricing/overview): how the three commercial units fit together
* [Individuals](/docs/pricing/individuals): individual plan product allowances
* [Teams](/docs/pricing/teams): team plan product allowances and add-ons
* [Agencies](/docs/pricing/agencies): agency plan product allowances, white-label, and handoff
* [AI credits and models](/docs/pricing/ai-credits-and-models): how AI capacity relates to products
* [Licenses and access](/docs/pricing/licenses-and-access): license management and reassignment
* [Implementation reference](/docs/pricing/implementation-reference): developer reference for product lifecycle events and billing hooks
# Teams
Source: https://productos.dev/docs/pricing/teams
Startup, Business, and Enterprise plans: license mixes, pooled AI credits, product allowances, add-ons, and upgrade paths.
Team plans cover startups, SaaS companies, and product departments that need multiple people working on multiple products simultaneously. You pay for the products you operate and the named licenses your team uses.
## Plan comparison
| | Startup | Business | Enterprise |
| ------------------------------- | ----------------------------------------------------------------------- | -------------------------------------------------------------------------- | -------------------------- |
| **Monthly price** | \$399 | \$1,199 | Custom |
| **Annual price** | \$3,990 (billed as \$333/mo equivalent) | \$11,990 (billed as \$999/mo equivalent) | Custom |
| **Active products** | 5 | 20 | 40+ |
| **AI credits** | 8,000 pooled / month | 25,000 pooled / month | Custom |
| **Model access** | Advanced + Frontier | Full Frontier access | Private + approved catalog |
| **Agent concurrency** | 5 | 15 | Custom |
| **Named members** | 5 (3 User Licenses, 2 Collaborator Licenses, unlimited Review Licenses) | 25 (10 User Licenses, 15 Collaborator Licenses, unlimited Review Licenses) | 50+ |
| **Add-on User License** | \$59/mo | \$55/mo | Custom |
| **Add-on Collaborator License** | \$15/mo | \$12/mo | Custom |
| **Add-on product** | \$29/mo | \$24/mo | Custom |
## Startup
\$399 per month, or \$**3,990 billed annually (displayed as \$333 per month).**
Startup is for early-stage teams bringing their first product portfolio to market. It gives you five active products, pooled AI credits, five named members, and the core admin controls needed to coordinate a small team.
### What is included
* 5 active products
* 8,000 pooled AI credits per month
* Advanced and Frontier model access
* 5 concurrent agents
* 5 named members: 3 User Licenses, 2 Collaborator Licenses, unlimited Review Licenses
* Shared design systems across products
* Per-member AI usage limits
* Admin-approved AI top-ups
* Roles and approval workflows
* Auto Router with member limits
### Add-ons
You can add licenses and products as your team grows:
| Add-on | Price |
| ------------------------------- | ------------ |
| Additional User License | \$59 / month |
| Additional Collaborator License | \$15 / month |
| Additional active product | \$29 / month |
### Who it is for
Startup fits teams of up to five builders who are shipping their first products. If you need to add more User Licenses, more products, or higher AI capacity, Business covers that without requiring a custom engagement.
### Switching to Business
Business adds 20 products, 25,000 pooled credits, 15 agents, 25 named members, model-level cost and quality analytics, department and product budgets, and credits that roll over for one billing cycle. If you are adding team members, managing multiple products across a department, or need visibility into which models are driving costs, Business is the upgrade.
***
## Business
\$1,199 per month, or \$**11,990 billed annually (displayed as \$999 per month).**
Business is for growing SaaS companies and product departments managing multiple teams and products. It gives you higher build concurrency, advanced permissions, model analytics, and rollover credits.
### What is included
* 20 active products
* 25,000 pooled AI credits per month
* Full Frontier model access
* 15 concurrent agents
* 25 named members: 10 User Licenses, 15 Collaborator Licenses, unlimited Review Licenses
* Higher build concurrency
* Advanced permissions
* Model-level cost and quality analytics
* Department, product, and member budgets
* Included credits roll over for one billing cycle
* Priority Router with model analytics
* Priority support
* Auto Router with member limits
### Add-ons
| Add-on | Price |
| ------------------------------- | ------------ |
| Additional User License | \$55 / month |
| Additional Collaborator License | \$12 / month |
| Additional active product | \$24 / month |
### Who it is for
Business fits product organizations that are operating multiple products across a growing team. The larger credit pool, product allowance, and named member limits accommodate most scaling teams without add-ons. If you need SSO, SCIM, private model routing, or custom volume, Enterprise covers that.
### Switching to Enterprise
Enterprise adds SAML or OIDC SSO, SCIM provisioning, domain claiming, Bring Your Own Model, model allowlists by team or product, regional AI data processing controls, private deployment options, invoicing and PO support, and dedicated migration and onboarding. Contact [enterprise@productos.dev](mailto:enterprise@productos.dev) to discuss custom terms.
***
## Enterprise
**Custom pricing, scoped to your requirements.**
Enterprise covers large product organizations with 50 or more members, governance requirements, compliance needs, or private deployment preferences.
### What is included
* 40 or more active products (custom)
* Custom committed AI capacity
* Custom concurrency
* Private and approved model catalog
* 50 or more named members (custom mix)
* Custom license mix and volume
* SAML or OIDC SSO and SCIM
* Domain claiming
* Bring Your Own Model and Bring Your Own Key
* Model allowlists by team, product, or stage
* Regional AI data processing controls
* Private deployment and data controls
* Invoicing, purchase order support, and SLA
* Migration and onboarding support
* BYOM and BYOK with private model gateway
### Who it is for
Enterprise is for organizations that need custom volume, enterprise authentication, compliance controls, or private infrastructure. Contact [enterprise@productos.dev](mailto:enterprise@productos.dev) to scope a plan.
***
## Credit pooling
On team plans, AI credits pool at the workspace level. This means all members share one credit balance. Admins can set budgets by product, department, or individual member, and decide which products may use Frontier models.
Review Licenses do not consume AI capacity because reviewers cannot run agents.
Included credits on paid plans roll over for one billing cycle. Purchased top-up credits follow the terms shown at purchase.
***
## Annual billing
Annual billing for Startup is \$3,990, priced at 10 months and billed once annually. The displayed equivalent is \$333 per month.
Annual billing for Business is \$11,990, priced at 10 months and billed once annually. The displayed equivalent is \$999 per month.
Annual billing simplifies budgeting and includes two months compared with paying monthly for a full year.
***
## Adding and removing licenses
Adding a User or Collaborator License is prorated for the rest of your current billing term. Removing a license takes effect at your next renewal, so your team keeps access through what you already paid for.
A paid license released mid-term stays available for reassignment to someone else for the remainder of that term.
Reassignment is auditable, with a reasonable cooldown and concurrency and device controls to prevent credential sharing.
***
## Related pages
* [Pricing overview](/docs/pricing/overview): how the three commercial units fit together
* [Individuals](/docs/pricing/individuals): for solo builder plans
* [Agencies](/docs/pricing/agencies): for client-facing delivery
* [AI credits and models](/docs/pricing/ai-credits-and-models): credit pooling, budgets, and top-ups
* [Licenses and access](/docs/pricing/licenses-and-access): full capability matrix and role definitions
* [Products, channels and billing](/docs/pricing/products-channels-and-billing): product lifecycle and billing mechanics
* [Implementation reference](/docs/pricing/implementation-reference): developer-oriented commercial contract
# FAQ
Source: https://productos.dev/docs/resources/faq
Frequently asked questions about ProductOS: how it differs from code-first builders, code ownership, mobile apps, pricing, and integrations.
## The platform
ProductOS is an AI product-building platform. You describe your idea once, and a pipeline of agents takes it from research to PRD to design to production code, web and mobile, with every stage sharing the same project context. See [What is ProductOS](/docs/getting-started/what-is-productos).
Those tools start at code. ProductOS starts at the product: research and a real PRD come first, the design is generated from that spec, and the code is built from both. You also keep full code ownership, with GitHub sync and export from day one and no export wall.
Yes. Native iOS and Android via Expo, from the same prompt and context as your web app, including store deployment. See [Mobile](/docs/code/mobile).
ProductOS has a \$0 Hobby tier for one personal draft, 100 monthly AI credits, and a branded pipeline preview. Shipping a production product requires Builder or another paid plan. See the [pricing overview](/docs/pricing/overview).
## Code ownership
Yes. Generated code syncs to your own GitHub repository as it is written. You can export the full codebase and deploy on your own infrastructure with your own domains. See [Code ownership](/docs/platform/code-ownership).
No, the opposite. GitHub sync exists so you own the code: the full codebase lands in your own repository, you can export it at any time, and you deploy it wherever you like. Integrations reduce lock-in rather than add to it.
Yes. Because the full codebase lives in your repo, you can connect it to your hosting provider and deploy from the branch you control. Further changes from ProductOS arrive as normal commits. See the [GitHub integration](/docs/integrations/github).
## Integrations
ProductOS integrates with Cursor and Claude over the Model Context Protocol (MCP) and syncs your full generated codebase to GitHub. Vercel, Figma, and Slack integrations are on the roadmap. See the [integrations overview](/docs/integrations/overview).
MCP is an open standard that lets AI clients like Cursor and Claude read from and write to external context sources. ProductOS exposes your project over MCP so those tools work against your real PRD, research, and designs instead of a pasted snippet. See [MCP](/docs/integrations/mcp).
No. The MCP connection to Cursor and Claude and the GitHub code sync are part of the core ProductOS workflow, and you can start free.
No. The integration brings the PRD, research, and design into the editor, so a product manager can direct Cursor with the same source of truth an engineer uses. You describe what you want; Cursor builds against the spec.
## Models and keys
Yes. You can plug in your own Anthropic, OpenAI, or Google keys, or an OpenRouter gateway key, instead of platform credits. See [BYOK and models](/docs/platform/byok-and-models).
Model choice per agent is configurable; no model is hardcoded into the pipeline.
Something not covered here? The [glossary](/docs/resources/glossary) defines the terms, and each surface's overview page ([Build](/docs/build/overview), [Code](/docs/code/overview), [Design](/docs/design/overview)) covers its own workflow in depth.
# Glossary
Source: https://productos.dev/docs/resources/glossary
The six most load-bearing terms in the ProductOS docs, with one-line definitions and a link to the full glossary on productos.dev.
The full ProductOS glossary lives at [productos.dev/glossary](https://productos.dev/glossary). It covers 30+ terms across product management and AI, each with a definition, comparisons, and FAQs. The six below carry the most weight in these docs.
| Term | Definition |
| --------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [AI agent](https://productos.dev/glossary/ai-agent) | A software system that uses a language model to plan and execute multi-step tasks toward a goal, calling tools, checking results, and adjusting without step-by-step instructions. |
| [Product requirements document (PRD)](https://productos.dev/glossary/product-requirements-document) | A structured specification that defines what a product should do and why: the problem, target user, scope, user stories, and acceptance criteria that guide design and engineering. |
| [Model Context Protocol (MCP)](https://productos.dev/glossary/model-context-protocol) | An open standard that connects AI models to external tools and data sources through one consistent interface, with no custom integration code per client. |
| [Code ownership](https://productos.dev/glossary/code-ownership) | The right to fully export, host, modify, and keep the source code a platform generates for you, so your product exists independently of any vendor or subscription. |
| [Bring your own keys (BYOK)](https://productos.dev/glossary/bring-your-own-keys) | A usage model that routes an AI tool's requests through your own provider API keys, so usage bills to your account and data flows under your own provider agreement. |
| [Design system](https://productos.dev/glossary/design-system) | A reusable library of components, design tokens, and usage rules that keeps a product's interface consistent as it grows across screens, features, and teams. |
Where these terms live in the docs:
* Agents and the pipeline: [Agents overview](/docs/agents/overview)
* PRDs in practice: [The PRD stage](/docs/build/prd)
* MCP in practice: [MCP integration](/docs/integrations/mcp)
* Code ownership in practice: [Code ownership](/docs/platform/code-ownership)
* BYOK in practice: [BYOK and models](/docs/platform/byok-and-models)
* Design systems in practice: [Brand and design systems](/docs/design/brand-and-design-systems)
# Showcase
Source: https://productos.dev/docs/resources/showcase
The ProductOS showcase: real projects and customer stories built end to end on the platform, with the brief, pipeline, and shipped result for each.
The showcase at [productos.dev/showcase](https://productos.dev/showcase) is the public gallery of things actually built on ProductOS. Every entry is a case study: it documents the brief, the surface and pipeline used, the stack, and the shipped result, with a link to the live deployed site. Nothing in the showcase is a mockup; each project has a real URL you can visit.
## What a case study contains
Each showcase entry documents:
* **The brief and summary.** What the product is and what problem it solves.
* **The surface used.** Which ProductOS surface built it (Build, Code, or Design) and a link to that surface.
* **The pipeline.** The actual steps the build went through, from brief and design system to deployment.
* **The stack.** The technologies in the shipped product (for example Next.js, Astro, Tailwind, Prisma, Neon Postgres).
* **Stats.** Concrete numbers from the shipped product where they exist.
* **The live URL.** The deployed site, typically on a `*.product-os.app` domain or the customer's own domain.
## Two kinds of entries
The showcase mixes two kinds of projects, and the distinction matters:
| Kind | What it is | Becomes a template? |
| --------------------- | -------------------------------------------------------------- | ------------------------------------------------ |
| **Showcase projects** | Internal projects built to demonstrate the platform end to end | Yes, when a reusable template exists |
| **Customer stories** | Products built by or for real customers | No, those builds are proprietary to the customer |
Customer stories are labeled with a "Customer story" category chip. Showcase projects carry a neutral project-type chip instead.
## Categories
Entries are typed by what they are, not by which surface built them. Categories across the showcase include web apps, web games, mobile apps, brand sites, hospitality sites, e-commerce stores, product launches, operations apps, analytics apps, coaching platforms, and community platforms. Customer stories add their own domain labels, such as travel platform, climate tech, education, robotics, automotive, and editorial.
A hand-picked set of projects carries a **Featured** badge and sorts to the top of the page.
## Showcase and templates
The [template directory](/docs/resources/templates) is derived from the showcase registry: every internal showcase project with a reusable template becomes a template you can open in Build, Design, or Code. The showcase is the proof; the template is the head start. If a showcase project catches your eye and it is not a customer story, there is a good chance you can start from it directly.
## Why it exists
The showcase is the honest answer to "what does the output actually look like?" Rather than describing the pipeline in the abstract, each entry shows what a specific brief turned into: the design system it got, the features that shipped, and the site running today. If you are evaluating ProductOS, start there, then clone the closest template and see how far it gets you.
Every project, live and clickable, at productos.dev/showcase.
# Templates
Source: https://productos.dev/docs/resources/templates
The ProductOS template directory: 14 real, shipped projects you can open in Build, Design, or Code instead of starting from a blank prompt.
Templates are real, shipped ProductOS projects you can start from instead of a blank prompt. The directory at [productos.dev/templates](https://productos.dev/templates) lists 14 of them, and every entry derives from the [showcase](/docs/resources/showcase): each template is a project that was actually built and deployed on ProductOS, not a mockup.
Templates are common across the three surfaces. Each one has an "Open in" picker that deep-links it into the surface you want to work in.
## Opening a template
| Surface | What happens |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Open in Build** | Opens [beta.productos.dev](https://beta.productos.dev) with a prompt prefilled from the template, so the full pipeline starts from that idea. |
| **Open in Design** | Opens the [design.productos.dev](https://design.productos.dev) template gallery to explore it as a design. |
| **Open in Code** | Clones the template into a live dev sandbox on [develop.productos.dev](https://develop.productos.dev). Templates with a true-clone entry in the Code registry clone directly; the rest open the Code template gallery. |
Five templates have true-clone entries in the Code surface's registry: SOLEN, Echo, StudioFlow, Lumen Notes, and Orbit. Cloning creates a fresh, private project of your own in an isolated cloud sandbox with a live preview URL.
Volume-backed templates boot in about 3 seconds, versus about 25 seconds for a tarball clone. See [Sandboxes](/docs/code/sandboxes).
## The directory
| Template | Category | What it is |
| ---------------- | -------------------- | -------------------------------------------------------------------------------- |
| **SOLEN** | Architecture (Astro) | A residential architecture studio site, the first ProductOS site built on Astro |
| **ORBIT** | Web game | A hybrid-casual game with its whole business model playable in the browser |
| **STUDIOFLOW** | Web app | A photography studio's client lifecycle in one pipeline, inquiry to paid |
| **Lumen Notes** | Web app | A clinical documentation product that turns a therapy session into a signed note |
| **ECHO** | Web app | A content repurposing SaaS: one podcast episode becomes a week of content |
| **CASA MIRADOR** | Hospitality site | A clifftop hotel site whose hero glides over the Atlantic |
| **FORMA** | E-commerce store | A furniture storefront with a cart that actually works |
| **VELA** | Brand site | A specialty roastery's launch page with a scroll-poured espresso film |
| **HALO** | Product launch | A smartwatch dissection page in the Apple design language |
| **RESERVA** | Operations app | Restaurant table management a maitre d' would actually use |
| **STRIDE** | Coaching platform | An endurance-coaching platform with activity rings |
| **AETHER** | Brand site | A cinematic athletic-brand launch site, from one prompt to deployed |
| **LEDGERLINE** | Analytics app | Revenue analytics a CFO would trust, shipped as a working app |
| **Mainspring** | Brand site | A brand site for an AI-automation agency |
Every template also links to its live deployed site, so you can try the real thing before you clone it.
## Templates and the showcase
The directory is derived from the showcase registry: internal showcase projects with a reusable template appear here. Customer success stories in the showcase do not become templates, because those builds are proprietary to the customer. Read more in [Showcase](/docs/resources/showcase).
## Where to go next
How cloning works on develop.productos.dev, including the template registry.
The design gallery on design.productos.dev.