---
title: "Praxis for founders"
route: "/for/founder"
description: "Keep decisions durable while a solo founder moves between product, architecture, implementation, and quality work."
template: role
intent: "Help a solo founder retain decisions while changing roles."
parent: "/for"
primaryCta: { label: "Choose your first harness", href: "/platform" }
schemaType: Service
hero:
  eyebrow: "Founder / solo"
  headline: "Change roles without losing the decisions you already made."
  sub: "Move from product to architecture to code without reconstructing the decision that made the work safe to start."
  primaryCta: { label: "Choose your first harness", href: "/platform" }
sections:
  - { id: pain, kind: pain, heading: "The solo context reset" }
  - { id: why-chat-memory-fails, kind: explanation, heading: "Why a chat cannot be your handoff" }
  - { id: multi-role-flow, kind: flow, heading: "Move roles through one versioned flow" }
  - { id: what-persists, kind: cards, heading: "What persists when you switch hats" }
  - { id: proof, kind: proof, heading: "What you can reopen tomorrow" }
  - { id: next-step, kind: cta, heading: "Choose the first role" }
---

## The solo context reset

You write the product intent in the morning, make an architecture choice after lunch, and code at night. Each shift asks you to rebuild the reasoning that was clear only a few hours ago.

## Why a chat cannot be your handoff

The conversation remembers a response until it does not. It does not give your future self an accepted requirement, an explicit decision, and evidence tied to the result.

## Move roles through one versioned flow

Start with the role that owns today’s decision. As BA, clarify and approve scope and create the initial canonical WP. Return as Architect to enrich that same package with technical choices. In a Developer session, verify that the prepared package and referenced files are available in the chosen code workspace before implementation. Quality Harness can review the result when needed.

## What persists when you switch hats

Accepted versionable artifacts can be reopened from the repository you maintain. Local Runtime journals, uncommitted changes, integration credentials and another machine’s setup do not follow you automatically; explicitly stage or synchronize the material needed for the next session.

## What you can reopen tomorrow

Open the accepted scope, stable WP identity, technical handoff, implementation evidence and any Quality findings. Check their revisions before resuming so a stale package does not silently become the current one.

## Choose the first role

Start with the harness for the responsibility you hold today, then connect the next handoff when the work crosses it.