Your whole team, with agents behind them.
Ship what you used to outsource.
p0 is BePurple's desktop app. Anyone on the team can drive it: a PM, a designer, a founder, an engineer. Our forward deployed engineers work alongside you where you want them.
Describe the feature. p0 writes the spec and the mockups.
Comments from the people who care, before anything is built.
Press Go, or hand it to a teammate with the whole context attached.
The spec becomes phased tasks. Agents build them in parallel.
QA verifies every criterion. Coordinated PRs land across every repo.
Inside the app
You never get code back that nobody checked. Every session p0 runs ends with verification: it builds what you asked for, then proves it works before a pull request is ever opened. A failure loops back and gets fixed, not handed to you.
Every session states what "done" means, then demonstrates it.
A failed check routes back into the work without stopping everything else.
The built-in browser drives the real UI. Click the thing you want changed.
You do not wire agents together yourself. p0 ships with the orchestration engine inside it: it splits a feature into phases, assigns each piece its own files so parallel agents never collide, and runs them together. The rebuilt engine ships better code in less time, on fewer tokens.
Two agents are never allowed to write the same file.
Describe one, p0 writes it, the whole team gets it.
Schedule builds overnight. Retries pick up when quota resets.
An enterprise feature is never one repository. p0 holds context across all of them, imports, API contracts, shared types, and opens coordinated pull requests so nothing drifts out of sync.
Imports, contracts and shared types understood together.
Every repo gets an isolated branch. Your main stays clean.
One feature lands as one reviewable set.
When a vendor leaves, the understanding leaves with them. p0 generates standards from your real codebase and keeps them current as it changes, so the knowledge stays with your team.
Read off what you actually built, not a template.
Updated as the codebase evolves, not left to rot.
Plain markdown your new engineers can read on day one.
PRs shipped, sessions run, spend per user, all attributable and finance-ready. The evidence you take back to the board that approved bringing development home.
What shipped, by whom, in what time.
Per user, per session, down to the token.
Teams see their own momentum.
Code generation happens on your computer, on isolated Git worktrees. Only codebase documentation and workspace setup sync, so your team can share them. Prompts go to the endpoint you configure, including a server in your own data centre.
Generation runs on your machine. Files never touch our servers.
Every feature gets its own Git worktree. Your main branch stays clean.
No training on your data. No third-party access.
Claude, Codex, Kimi, DeepSeek, GLM, OpenRouter, or a model on your own hardware. A desktop app on macOS or Windows, with an endpoint that can stay inside your network.
Bring the provider you already pay for.
Nothing has to leave your network.
Model suggestion matches the model to the task.
p0 is yours to run. Where the work needs it, or where you want it, BePurple embeds forward deployed engineers alongside your team: they learn the stack, set the standards, and ship the first features on p0 with your team watching how it is done.
Our engineers sit with your team, on your codebase, in your review process. The work happens in-house from day one.
Everything we learn about your architecture gets written into standards your team keeps, whether we stay or not.
The measure of a good engagement is that your team keeps shipping after it ends. That is the whole point.
One scoped pilot, one feature your team has been waiting on a vendor for. By the end your team is running p0 itself.
For three decades, enterprises rented software development. AI flips the math: a small in-house team now ships faster than any vendor, and the knowledge stays.
On-prem systems, in-house frameworks, languages nobody at a startup has touched in a decade. p0 works in the system you have, not the one you wish you had.
Software you buy off the shelf because building it was impossible is now something your team can build and own.
Six months and a seven-figure invoice becomes work your team does in-house, and keeps.
Local execution, isolated worktrees, your own model endpoint. Built for organisations that have a security review.
A supplier reverse-bidding platform stuck on premise. The incumbent vendor quoted $1M+ and more than a year for the migration.
Four weeks of forward-deployed engineering, one week on site. The full auctioning platform rebuilt on p0: buyer and supplier user management, integrations into the existing ecosystem.
Their own team ships on p0 now, and other teams inside the OEM are running pilots of their own.
Their engineers ship on p0 without us in the room. That is the proof the work came home: not a hand-off document, a team that keeps going.
Our incumbent vendor quoted seven figures and more than a year to move one platform off premise. We rebuilt it in four days and we have been shipping on it ever since. What the board actually cares about is that the system, and the people who understand it, are ours now.
If someone came in and AI-readied our codebase, it alone would be worth the money. The standards BePurple generated taught us things about our own architecture we'd never documented.
I was convinced AI couldn't handle our 800k line monorepo. BePurple proved me wrong. The context management is genuinely impressive. It actually understands how our services connect.
Everything you need to know about how p0 works, what it can do, and how to get started.
The building blocks already exist. Claude Code, Codex, Cursor, subagents, plan mode, codebase indexing: the primitives for AI-powered development are here, and they work. But primitives aren't a workflow, and a workflow is what actually ships software.
In Claude Code, Codex, and Cursor, you're still the orchestrator: you prompt, review, re-prompt, and stitch things together yourself. p0 is to Claude Code and Codex what Rails was to Ruby. The language was always powerful; the framework made it productive.
p0 provides the workflow layer: you and AI collaborate on a product spec, and p0 builds even the most complex things while you work on the next feature in parallel. Our rebuilt orchestration engine breaks your request into atomic tasks with explicit file ownership, assigns them to specialized agents, resolves dependencies, runs QA loops, and delivers production-ready PRs. You can schedule a build for tonight or next Monday, and if you hit a rate limit it picks up automatically the moment your quota resets.
All you have to do: review the PRs.
You don't switch, you level up. We actually use Claude Code and Codex under the hood. What we built is the workflow around them: automated codebase readiness that stays current, interactive spec refinement grounded in your actual code, and opinionated orchestration that decomposes specs into parallel workstreams.
If you have a great Claude Code setup, p0 takes that and makes it a repeatable process for your whole team. You can also describe the agents you want (a reviewer, a migration specialist, a compliance checker) and Custom Agents Studio writes them, you edit them, and your whole team gets them.
Plan Mode in tools like Claude Code or Codex is an excellent way to create a brief plan to keep AI on task for smaller to medium sized changes. From our experience, it works really well as long as the scope isn't beyond that.
But when you try to implement the kind of product feature that would have taken you a week as a human team in a single shot, it almost never works. It will run out of context quickly because it does not split the work well, it'll be confident to be done without ever having tested anything, and it simply doesn't give you the ability to create specs with more details than the one-pager or so that it favors.
We've worked on fine-tuning our orchestration layer for a long time now, and the difference shows up on the work that takes a team a week rather than an afternoon.
That really depends on how you are approaching things. p0 tries to generate code "standards" (as we call them) that are easy to search by topic, don't clutter an agent's context, and provide instructions across a multi-repo setup for a holistic understanding that can be shared across your team.
Today, do you just rely on Claude or Codex reading through your code every time? This works for small changes, but runs into problems quickly: Reading entire files clogs context windows, and your code isn't necessarily written in a way that you aspire things to be done.
Is your codebase documentation in AGENT.MD files already? That's a good start. But these tend to be massive and suffer from the same context clogging as the above.
Have dozens of markdown files, each documenting specific aspects of how you do things? You've done the hard work then, but you still need to somehow share them with your team and need to create a level of documentation above your multi-repo to allow agents to understand how the stacks all connect.
p0 helps with all of these: It creates a draft of standards based on templates that we have developed to work well for agent use. This way nothing gets ignored, and you get to review and change things. We then allow you to share them with all team members so they don't have to create these again.
p0 is language- and framework-agnostic. During onboarding, it analyzes your stack and generates Standards tailored to it. We've worked with Next.js, React, Python, Node, TypeScript, Go, and more. If your team codes in it, p0 can work with it.
Yes. That is the case we are built for. On-premise systems, in-house frameworks, and languages nobody at a startup has touched in a decade: p0 works in the system you already have, not the one you wish you had.
It reads your actual codebase and generates Standards from what is there, so agents work to your existing conventions instead of a greenfield default. It is also multi-repo aware, which matters because an enterprise feature is rarely one repository. It is a service, a frontend, a shared contract, and something old nobody wants to touch.
Software you buy off the shelf because building it in-house was impossible is in range too. With the right system, your own team can build, shape, and own it.
Both. Chat mode handles quick changes: a copy fix, a small refactor, a one-line adjustment, without writing a spec first. The refine flow does the same for changes to something p0 already built.
Spec mode is for work that needs decomposition: a feature that spans several repositories, or a rebuild that would take a human team weeks. You pick the mode that fits the change, and both run in the same workspace against the same Standards.
p0 works with Claude Code, Codex, and any Anthropic-Messages-API-compatible endpoint: Kimi, DeepSeek, GLM, OpenRouter, or a gateway you host yourself. Add a provider in settings with your own base URL, token, and model list. You bring the subscription or API key; the provider bills you directly.
If you'd rather not pick per task, Model Suggestion reads the task, judges how much it actually demands, and proposes a model to match. p0 is tuned for frontier models like Claude Opus (1M context), so smaller models trade quality for cost.
Yes. p0 includes specialized QA agents in the pipeline. For example, a web page QA agent can use Playwright MCP to navigate around and take screenshots. An API tester agent can probe your work on endpoints.
p0 also has a built-in browser that renders your running app. Click any element and the agent gets the screenshot, the styles, and the exact component and line. The better your test cases, the better the outcome.
Yes, via Figma MCP servers. You can also define UI directly in your product spec (layout, components, interactions) and p0 will implement it using your existing design system and component library. Mockups and other prototypes can be provided to p0 directly as well.
Both. p0 has a built-in refinement flow that transforms rough ideas into detailed product specs through guided questions. And unlike chatting in Claude, Codex, or ChatGPT, it has a full picture of your codebase, so it can be smarter in its feedback.
You bring the vision; p0 helps you articulate flows, edge cases, and acceptance criteria, all within the context of your existing product. The better the spec, the better the code, that's why we help you make it as good as it can be.
Specs are built for review. Share one with your team, collect feedback, and iterate. Session Hand-off sends a whole spec or build to another engineer's inbox with a preview, and you can reclaim it any time before they accept.
Both. p0 works with Claude Code and Codex. Pick whichever your team already uses. And if you'd rather run something else entirely, you can point p0 at any Anthropic-compatible endpoint, including one you host yourself. The orchestration, spec workflow, and standards layer sit on top of whichever you pick.
p0 runs locally on your machine and works directly in your Git repositories. It creates branches, makes commits, and produces clean diffs you can review and refine. It fits into your existing PR and CI/CD workflow, and supports multiple concurrent sessions without mixing features in progress.
p0 is a native desktop app (macOS and Windows) that runs locally. Your code never leaves your machine. AI model calls send only the relevant context needed for each task, and you control what gets sent. There's no cloud copy of your codebase.
Your code stays on your machine. p0 is a native desktop app, generation runs locally in isolated Git worktrees, and there is no cloud copy of your codebase.
Prompts go only to the model endpoint you configure. That can be a provider like Anthropic or OpenAI, or a model you run yourself on your own servers. Point p0 at an internal endpoint and nothing about the workflow changes, and nothing leaves your network.
One thing to know before a security review: by default p0 syncs codebase documentation and workspace setup through our cloud so your team can share them. Whether that sync can be turned off for a fully air-gapped deployment is {{TBC}}. Ask us and we will confirm in writing.
Claude, Codex, Kimi, DeepSeek, GLM, OpenRouter, or a model you run yourself on your own hardware. p0 talks to any Anthropic-Messages-API-compatible endpoint, so you add a provider in settings with your own base URL, token, and model list.
Running your own is a first-class path, not a workaround. Point p0 at an internal endpoint and the orchestration, spec workflow, and standards layer are unchanged. You bring the subscription or API key and the model provider bills you directly, so that relationship stays yours.
If choosing per task is a chore, Model Suggestion reads the task, judges how much it actually demands, and proposes a model to match.
Your team does. p0 works inside your Git repositories: it creates branches, makes commits, and opens PRs that your engineers review, approve, and merge under the process you already have. What lands is ordinary code in your repository, and your engineers are accountable for it. That is the point, not a caveat.
Standards are plain markdown generated from your own codebase and kept with it. They are readable by your team, not just by agents, so the same document that steers an agent also onboards a new hire.
When a vendor leaves, the understanding usually leaves with them. Here it stays: if you stop using p0, the code and the standards are still yours and still where you left them.
Yes. You create workspaces, which can be a group of repositories or a single standalone repo. Standards are generated on top, so the documentation also covers how multiple repos interact with each other.
BePurple is the company. p0 is the product: our native desktop app for Mac and Windows that orchestrates AI agents to ship features in your codebase. When you work with BePurple, our team helps you get set up; p0 is the tool your team uses day-to-day.
Self-service gets you running your first feature in 30 minutes or less: install p0, let it analyze your codebase, review the Standards it drafts, then write your first spec. If you'd rather not do that alone, our forward-deployed engineers can run the first feature with you.
Our forward-deployed engineers embed with your team, onsite or remote. They analyze your codebase, generate the first set of Standards with you, and ship a real feature together, not a demo. Your engineers do the reviewing and the merging from day one, because the goal is a team that runs this itself.
Scope is set per customer. In practice it has looked like a few weeks of forward-deployed engineering with a week on site. The teams we work with ship on p0 themselves, without us in the room.
Bringing development in-house is an organisational change as much as a technical one. Our forward-deployed engineers exist because of that.
p0 ships native desktop builds for macOS and Windows. Windows is a full native build, not a wrapper or a virtual machine, and it shipped in 2026. Linux is not currently supported.
Beyond the app, p0 needs what your engineers already have: your Git repositories, your editor, and access to the model endpoint you've chosen. It runs on the machine in front of you, not on a server we operate.
We have three self-serve plans (Hacker, Pro, AI Team) and a custom enterprise tier (Scale). Each self-serve plan is a monthly subscription that includes a dollar amount of model usage. Model providers (Anthropic, OpenAI) bill you directly for AI usage; BePurple adds a small fee only on the model spend above your included amount. See the pricing page for the full breakdown.
Both macOS and Windows have native builds, and they get the same orchestration, spec workflow, and Standards. Linux is not currently supported.
Pick something your team has been waiting on a vendor for.