potpie
Book a demo

Collaborative spec creation

Context starts before the first line of code.

A business request doesn’t arrive as an engineering spec. Bring product, business, engineering, and security into one conversation—before anyone starts coding.

Book a demo
potpie/Team activation
AMPNSKJR4 contributors
SPEC-024 In review

Self-serve team trials

Let new teams experience the product together, without waiting for a sales call.

PNPriya Nair · ProductUpdated 3m ago

The problem

Campaign visitors can request a demo, but can’t try the product with their team. Every trial needs a manual setup.

What we’re building

A self-serve trial using our existing workspace service.

Users can invite teammates after verifying their work email. Each trial workspace is isolated.

3

Acceptance criteria

  • A verified user can create one trial workspace.
  • Teammates join through an email invitation.
  • Trial data is isolated from other workspaces.
Source: Team activation brief
Saved to project context3 decisions · 1 open question
Sample workspace Select a view to explore the spec.

The brief comes from the business.
The spec comes from the team.

A business analyst brings the rules. Marketing knows the customer journey. Product sets the scope. Developers know what can be built, and security knows what needs protecting.

Potpie gives that conversation a shared home, so the reasoning becomes part of the specification—not something lost between meetings.

Business analystsProduct & strategyMarketingEngineeringSecurity

Think together.
Build from the same spec.

From the first brainstorm to the next decision, keep your team and your agents working from one shared understanding.

Brainstorm with your team.
And Potpie’s agent.

Explore ideas together, with an agent that brings your engineering context into the conversation.

The whole history,
behind every spec.

Create specs with the full historical context of your code, docs, tickets, and past decisions.

Different perspectives.
Shared intent.

Capture the why together, resolve conflicts, and agree on what should be built.

Clear to people.
Actionable for agents.

Generate one spec with explicit scope, constraints, and acceptance criteria that both can understand.

From agreed spec
to agentic development.

Use the spec to guide agents as they plan, build, and verify the work—with your team in review.

A living spec.
Not a static handoff.

When decisions change, the spec updates with them. Keep intent and implementation in sync.

From discussion to decision

Work through the details.
Before they become rework.

Bring every perspective together. Turn the decision into a spec everyone can build from.

  1. 01Bring every perspective

    Product

    Invite teammates

    Security

    Verify work email

    Engineering

    Reuse the existing flow

  2. 02Find the shared answer

    One question

    Who can invite?

    Potpie
    Resolved together

  3. 03Build from the decision

    Shared spec

    Team invitations

    Verify before inviting.

    Decision captured

Part of your engineering context

The decisions stay
with the work.

The spec connects business intent to the systems, tasks, and constraints that shape implementation. Developers and agents get the reasoning alongside the requirement.

No second round of piecing together what everyone meant.

Spec-driven project management Explore the context graph
TEAM TRIALS / SPEC-024v0.4

Team invitations

The requirement and the context behind it.

JiraVerify work emailENG-142 · Acceptance criteria attached
GitHubworkspace-serviceExisting provisioning & invitation flow
Trial data isolationSEC-08 · Decision from security review

Questions & answers

A little more context.

Who can start a spec?

A business analyst, product manager, strategy lead, marketer, or anyone with a requirement. Start with the problem in plain language. Developers and security reviewers add their expertise as the spec takes shape.

Does everyone need to understand the codebase?

No. Business teams explain what needs to happen and why. Engineers connect that requirement to how the system works. The shared spec gives both groups a place to resolve questions without asking everyone to become technical.

What happens to unresolved questions?

They stay visible in the spec, with an owner. Feasibility concerns, data-handling requirements, and open decisions should be addressed before the team commits to implementation. A generated document isn’t a substitute for the team’s review.

How does this connect to development?

The agreed scope, acceptance criteria, and constraints become the starting point for project planning and spec-driven development. Developers and agents carry the business reasoning forward rather than piecing it together again from messages and meetings.