---
title: "Praxis for Startups"
route: "/startups"
template: size
intent: "Help a small team move between responsibilities without dropping context."
primaryCta: { label: "Choose a harness", href: "/platform" }
description: "A small team can start with one role harness and keep accepted scope, technical decisions and implementation evidence connected as responsibilities split."
schemaType: WebPage
sizeTone: "pain-first-quick-start"
hero:
  eyebrow: "For Startups"
  headline: "Let a small team change roles without dropping context."
  sub: "Start with the responsibility in front of you. Keep the request, technical choices and implementation evidence openable as the team grows."
  primaryCta: { label: "Choose a harness", href: "/platform" }
  secondaryCta: { label: "Talk to us", href: "/enterprise#contact" }
sections:
  - { id: pain, kind: pain, heading: "Small team, whole product" }
  - { id: why-more-agents-add-coordination, kind: explanation, heading: "Why \"just move fast\" stops working" }
  - { id: multi-role-method, kind: explanation, heading: "Product engineers, not process" }
  - { id: first-flow, kind: flow, heading: "How it works for a small team" }
  - { id: proof, kind: proof, heading: "The case" }
  - { id: next-step, kind: cta, heading: "Get moving" }
---

## Small team, whole product

At a startup every engineer is half the stack and the whole product at once. Requirements live in a founder's head, the design lives in whoever wrote the first version, and "done" means it demoed. AI made each person faster — and made it easier to ship code nobody planned, on a codebase nobody fully remembers.

## Why "just move fast" stops working

Speed without a shared process compounds: the third engineer rewrites what the first one meant, the assistant follows whichever convention it saw last, and the fix for last week's feature breaks this week's. A bigger company would hire analysts, architects, and QA. A startup cannot — and adding meetings is the one thing that kills the pace you hired for.

## Product engineers, not process

A founder can begin with BA to turn an uncertain request into accepted scope and the initial canonical WP. Architect enriches that same WP with the technical plan when needed; Developer implements a bounded change from the prepared handoff. Quality Harness can inspect the result. People can hold several roles over time without installing every harness at once.

## How it works for a small team

- **One question at a time** — choose the role that owns the current decision.
- **Shared package identity** — BA creates the initial canonical WP; Architect preserves and enriches it.
- **Explicit setup** — if code lives in another repository, make the prepared package and referenced files available there before Developer starts.
- **Reviewable result** — record checks that ran, failed or were skipped, and request Quality review as needed. Git delivery remains a separate approval.
- **Supported environments** — follow the documented Claude Code CLI or Claude Desktop/local Runtime path for the chosen role.

## The case

The [Digital Winery case](/cases/digital-winery) describes a product context where intent, operations, and production change need a linked delivery record. Public outcomes are omitted until publication evidence is approved.

## Get moving

Choose the harness that fits the responsibility you hold today, or talk to us when the team needs a shared delivery flow.