Introducing Projects-as-Code

There was a time when infrastructure lived in slide decks.

If you wanted to know how production was set up, you dug through diagrams, asked the senior engineer, and hoped the wiki page you found wasn’t written for a world that no longer exists. Then Infrastructure-as-Code changed the default. Not because files are elegant, but because they made the most important layer of software reproducible.

Projects—and, by consequence, project management—never received that treatment.

This does not pertain to the work itself, but to how the work is structured. The structure, the rules, the permissions, the automations, the meaning of a state, the definition of “ready,” the shortcuts you take during incidents, the approvals you insist on during launches. That layer still lives inside SaaS UIs, outdated docs, and your team's memory.

Where projects are today

Most teams have “a process,” but they can’t recreate it on demand.

They can’t reliably spin up the same operating model for a new region, a new team, a new product line, or a regulated environment. Not because they’re sloppy. Because the operating model isn’t a first-class artifact, it’s a result of clicks and memory.

The cost nobody budgets for

Onboarding feels like archaeology.

You hear the usual lines—“we do Kanban but also sprints,” “incidents go here unless it’s urgent,” “there’s a doc somewhere”—and then you learn the real rules the hard way. Which labels matter. Which states are ceremonial. Which work item types enforce fields. When QA is required and when it’s quietly bypassed. Which automation exists, what it edits, and why nobody trusts it.

Drift isn’t a moral failure. It’s physics. If your operating model lives in UI configuration and tribal knowledge, it will drift.

This drift manifests in several ways,

• Two teams claim they run "the same workflow" while behaving differently
• Statuses mean one thing on the board and another in practice
• Process changes are made mid-incident and never formalized
• Permissions are loosened "temporarily" and remain that way.

Project configuration is production

Here’s the part we don’t say out loud often enough: project configuration is production.

In infrastructure, we don’t accept “someone edited prod settings in a UI” as governance. In project tools, we accept it every day. Workflows change without review. Permissions loosen for speed. Automations evolve into mystery boxes. Most tools might tell you who edited something, but rarely what changed in a way you can test, reason about, or roll back.

Templates and cloning help, but they don’t solve this. A template gives you a starting point. It doesn’t give you a source of truth, a diff, validation, or a way to keep many projects aligned over time.

While individual boards can be cloned, centralized governance across multiple boards remains unachievable.

Projects-as-Code

Projects-as-Code means a project’s operating model becomes a first-class artifact.

Not a doc describing how work should happen, but a declarative spec that defines how work does happen: how work items are structured, how workflows and states behave, what rules apply to transitions, who can do what, and what automation runs on which events.

These configurations are stored as files, versioned in Git, and changed through pull requests.

In plain terms, it looks like a project having a home on disk, next to your code—types, workflows, labels, automations—so you can open a folder and see how the project actually works. A workflow change becomes a diff. An operational policy becomes reviewable, not implicit.

What belongs in the spec

You don’t need to encode preferences. You need to encode governance.

Start with the elements that contribute to drift and coordination costs,

• Structure
  Defining work item types, required fields, and defaults.
• Flow
  Specifying workflows, states, and transition rules.
• Control
  Establishing roles and permissions (where supported).
• Automation
  Outlining event-based rules, schedules, and escalation policies.

Everything else can remain flexible.

What changes when you do this

Once the operating model is versioned, the org changes in ways dashboards never achieve.

• Reproducible expansion
  Spin up a new team or region without re-clicking and hoping
• Reviewable change
  Workflow updates stop being admin actions and become diffs
• Auditable truth
  “When did we change this rule?” becomes Git history, not memory
• Consistency without force-fitting
  Standardize foundations, allow controlled variation

What it looks like in practice

This is a declarative spec of the project itself,

projects/
  core-platform/
    plane.yaml
    schema/
      types.yaml
      workflows.yaml
      labels.yaml
    automations/
      sla-escalation.yaml
      auto-assign.yaml
    work/
      backlog.yaml

Declaring a project as code

And, here is a simplified example of a project defined with Plane Compose,

workspace: acme-corp
project:
  key: CORE
  name: Core Platform
  uuid: a4730c38-0d4d-4dbc-bb11-f1c4f8618904
defaults:
  type: task
  workflow: standard

This is your core plane.yaml file. It defines which Plane workspace and project this configuration belongs to, along with default settings for new work items.

How you use it

Projects as Code needs the same basic lifecycle IaC made normal: initialize, inspect, apply, and sync.

In Plane, this workflow is expressed through Plane Compose:

• plane init
• Initialize a new Plane project with local configuration files
• plane pull
• Pull the latest schema and work items from Plane
• plane push
• Push local changes to your Plane workspace
• plane status
• Show what would change if you pushed
• plane schema
• Validate and manage your schema files

Where we go from here

Projects-as-Code is about treating projects—the way work actually flows through your company—as a first-class artifact, not a consequence of clicking around in a project management UI.

Plane Compose is our way of making that real: a declarative format, a CLI to validate, sync, and apply, and a foundation for sharing and reusing project patterns across teams.

We’re early, but the direction is clear. Infrastructure as Code gave us reproducible environments. CI/CD gave us reproducible delivery. Projects as Code gives us reproducible ways of working.

If your projects feel like snowflakes, if workflows drift, if onboarding feels like archaeology, this is the direction you’ve been waiting for.

Projects should be code. If you want to experiment, start small. Define a single project with plane.yaml and schema files. Capture workflows and work item types. Put it in Git and run it through review.

The next piece is the implementation layer: Plane Compose, the framework we’re building to make this real inside Plane.