---
title: "Praxis — the open method for AI-native software delivery"
route: "/"
template: home
intent: "Explain the connected delivery method and help a visitor choose a harness or the full chain."
primaryCta: { label: "Explore the harnesses", href: "/platform" }
description: "Praxis is an open method and toolchain for AI-native software delivery: Business Analyst, Architect, Developer, and Quality Harness connect through reviewable artifacts. A separate private Quality Platform is planned for project histories."
schemaType: Organization
hero:
  eyebrow: "Role harnesses · AI-native delivery"
  headline: "AI made everyone faster. Keeping the work together still falls on you."
  sub: "Praxis is an open method and toolchain for building software with AI: Each role has a harness for its part of the work. Shared requirements, work packages, and evidence help the next person continue without rebuilding decisions from chat. Quality Harness reviews a particular result; the separate private Quality Platform is planned for history across projects."
  primaryCta: { label: "Explore the harnesses", href: "/platform" }
  secondaryCta: { label: "Talk to us", href: "/enterprise#contact" }
sections:
  - { id: strip, kind: cards, heading: "What Praxis is" }
  - { id: shift, kind: text, heading: "AI put an agent on every desk. It did not put them on the same team." }
  - { id: method, kind: pipeline, heading: "Four role harnesses, one connected method." }
  - { id: roles, kind: cards, heading: "Install one role, or run the whole flow." }
  - { id: engineers, kind: text, heading: "Developers become product engineers." }
  - { id: trust, kind: cards, heading: "Craft shifted to AI. Accountability didn't." }
  - { id: opensource, kind: text, heading: "Your canon stays inspectable." }
  - { id: cases, kind: cases, heading: "Built with the lifecycle, running in production." }
  - { id: cta, kind: cta, heading: "Start growing products." }
lenses:
  situations:
    - { id: "only-launching", label: "Only launching", pain: "Code appears before you can say what must be ready.", mechanism: "Turn intent into a requirement, a design decision, and a small verified increment.", flow: "Intent → requirement → design decision → verified increment", firstStep: "Start where the product decision needs to become clear.", href: "/solutions/by-stage/starting-a-product", cta: "Read the BA guide" }
    - { id: "recently-launched", label: "Recently launched", pain: "Every request reopens decisions that were never made visible.", mechanism: "A change request traces the impact before implementation begins.", flow: "Change request → impact links → updated decision → evidence", firstStep: "Start with the change that keeps falling through context gaps.", href: "/solutions/by-stage/after-launch", cta: "See traceable change" }
    - { id: "team-delivery", label: "Team is delivering", pain: "Everyone has agents, rules, and shortcuts. You still connect the results by hand.", mechanism: "A versioned output from one role becomes the next role’s input.", flow: "Role output → named handoff → human gate → next input", firstStep: "Run one real package through the connected chain.", href: "/solutions/by-stage/team-delivery", cta: "See the connected method" }
  roles:
    - { id: "founder-solo", label: "Founder / Solo", pain: "Changing roles means reopening your own decisions.", mechanism: "Artifacts survive the session and the role change.", flow: "Intent → decision → role change → retained artifact", firstStep: "Choose the responsibility you hold today.", href: "/for/founder", cta: "Choose your first harness" }
    - { id: "head-of-product", label: "Head of Product", pain: "The meaning of the requirement breaks apart on the way to engineering.", mechanism: "Intent, rules, acceptance, and evidence remain traceable.", flow: "Intent → requirement → acceptance → evidence", firstStep: "Start with the requirement handoff.", href: "/for/head-of-product", cta: "See the requirement handoff" }
    - { id: "engineering-director", label: "Engineering Director", pain: "Individual demos speed up while review, integration, and rework still land on you.", mechanism: "Shared standards and gates turn personal practices into delivery.", flow: "Standard → handoff → gate → evidence", firstStep: "Map one delivery flow with the team.", href: "/for/engineering-director", cta: "Map one delivery flow" }
    - { id: "developer", label: "Developer", pain: "Generation is quick. Reconstructing decisions and acceptance is not.", mechanism: "A bounded package arrives with decisions and leaves with evidence.", flow: "Package → plan → change → evidence", firstStep: "Start with the package you receive.", href: "/for/developer", cta: "Read the Developer setup" }
    - { id: "quality-lead", label: "Quality Lead", pain: "AI code grows faster than your visibility into quality and security drift.", mechanism: "Review one result with Quality Harness; discuss private multi-project history separately.", flow: "Harness review → approved application; planned Platform → history per project", firstStep: "Talk to us about private Quality Platform access.", href: "/for/quality-lead", cta: "Talk to us about private access" }
---

## What Praxis is

- **A harness for your role** — BA, Architect, Developer and Quality Harness guide distinct responsibilities. Choose the one that serves your current work.
- **A connected contract** — accepted scope, a prepared package and evidence let the next person inspect the decision.
- **A reviewable transition** — proposed canonical writes, Quality application and Git delivery each have their own approval boundary.
- **A durable record** — versionable artifacts can live in your repository; local Runtime journals and cross-machine setup need their own handling.

## AI put an agent on every desk. It did not put them on the same team.

AI makes a person faster at the task in front of them. The coordination cost remains when a requirement is accepted in one session, designed in another, and implemented against a ticket that omits the decision. Praxis gives each role an artifact the next owner can open. Review or rework can still send the package back; the method keeps that decision visible.

## Four role harnesses, one connected method.

The delivered role chain is **Business Analyst → Architect → Developer → Quality Harness**. BA clarifies and accepts scope and creates the initial canonical work package. Architect enriches that same package with relevant technical decisions. Developer inspects the prepared input, implements a bounded change and records checks, failures and skips. Quality Harness reviews that particular result. Applying its findings and publishing through Git require their own approvals; a published PR or MR still awaits human review and merge.

A separate private **Quality Platform** is planned to keep quality history within each project and provide oversight across multiple projects. That future history is not a claim that every current review creates a live trend.

## Install one role, or run the whole flow.

- **Business Analyst** — make a raw request and its acceptance reviewable. [Read the BA guide](/docs/plugins/ba).
- **Architect** — enrich accepted scope with the technical choices the selected change needs. [Read the Architect guide](/docs/plugins/architect).
- **Developer** — check the package and repository context, implement, and return evidence. [Start in Claude Code CLI](/docs/getting-started/cli).
- **Quality Harness** — inspect an individual result and preview any application. [Read the Quality guide](/docs/plugins/quality).

Each package has its own distribution and prerequisites. Current workflows include Claude Code CLI and Claude Desktop/local Runtime paths; the [setup guide](/docs) separates them.

## Developers become product engineers.

A developer needs accepted intent and relevant design to own the resulting feature. The prepared package brings those links together, but its referenced files must be accessible in the code workspace. In a team setup, BA and Architect can share a product repository while Developer works in a code repository; transferring the prepared package is an explicit step. Runtime does not automatically sync a sibling checkout.

## Craft shifted to AI. Accountability didn't.

Use the harness to expose what a person is deciding: proposed scope, technical tradeoffs, implementation evidence and Quality findings. A verdict reports a particular operation, including skipped checks where relevant. It does not imply that every build, test, lint or security check ran. Keep the working record available for the next role and explicitly stage the versionable parts you choose to publish.

## Your canon stays inspectable.

The BA, Architect and Developer paths and a delivered Quality Harness have distinct package surfaces. The filesystem canon can be versioned in your Git repository; `.project` is its configuration file. The private Quality Platform is a separate product direction with access discussed in conversation.

## Built with the lifecycle, running in production.

These cases describe product contexts and the method used there. They do not imply today's Runtime or private Platform was used historically, and public outcome metrics stay out until their publication evidence is approved.

- **Digital Winery** — operational information, rules and production change. [Read the case](/cases/digital-winery).
- **Watchlink** — decisions through a changing community experience. [Read the case](/cases/watchlink).

## Start growing products.

Choose the responsibility you hold today. Begin with one accepted scope or prepared package, then bring the next role in when the work needs it.