Auteur playbook · SaaS / web application

Build one valuable workflow across every required layer.

A SaaS feature is not a screen. It is a durable state transition across interface, client logic, authorization, services, data, integrations, feedback, and recovery.

Complete build process

Five stages from capability to dependable product behavior.

The unit of delivery is a vertical workflow. Every stage preserves the connection between user value, stored state, system behavior, and evidence.

01 · FRAME

Define the user and system decisions

Name the user moment, desired outcome, source evidence, system authority, and consequences of an incorrect result.

Work

  • Map current workflow and failure cost
  • Separate user input, system inference, and external truth
  • Identify data, privacy, latency, and authorization constraints

Artifacts

  • Product intent statement
  • Evidence and assumption ledger
  • Risk and authority boundary

Exit when: the team knows what the product may decide, what the user must approve, and what could cause harm.

02 · DIRECT

Design the vertical feature slice

Specify the journey and trace it across UI, client state, API, service, data, integrations, and operations.

Work

  • Define states, transitions, contracts, permissions, and provenance
  • Choose in, out, and later boundaries
  • Specify tests by layer and between layers

Artifacts

  • Feature matrix
  • Data and API contracts
  • Executable plan with rollback

Exit when: every required layer, connection, failure path, and acceptance check has an owner.

03 · DELIVER

Implement the smallest end-to-end journey

Carry one useful action through real persistence and feedback before expanding feature breadth.

Sequence

  • Schema and migration
  • Domain service and policy
  • API contract and authorization
  • Client service, state, UI, and feedback

Delivery discipline

  • Verified commits at coherent checkpoints
  • Feature flags for risky exposure
  • Observable events and errors
  • Document decisions as they change

Exit when: one real user journey crosses the system and can be safely reversed or disabled.

04 · VERIFY

Prove components and connections

Test correctness inside each layer, contracts at each seam, and behavior through the rendered product.

Evidence

  • Unit, policy, and data-integrity tests
  • API contract and integration tests
  • End-to-end journey and authorization checks
  • Failure, retry, idempotency, and recovery tests

Independent review

  • Product intent
  • Security and privacy
  • Regression and maintenance
  • AI quality and human control where applicable

Exit when: observed evidence supports the release criteria; “the code exists” is not evidence.

05 · LEARN

Observe production and update the rules

Compare real behavior with intended value, reliability, cost, and risk.

Work

  • Monitor activation, completion, correction, failure, latency, and cost
  • Review support evidence and surprising user behavior
  • Turn incidents into tests, guardrails, and revised specifications

Artifacts

  • Current feature status
  • Incident and decision records
  • Next vertical slice or stop decision

Repeat when: evidence changes the workflow, authority boundary, quality bar, or economic case.

Worked example

Vivid Resume: one grounded recommendation for one target job.

The vague request is “generate a better résumé.” The useful slice connects a real opportunity to user evidence and preserves review.

  1. 01

    Frame

    A user wants relevant application material without invented experience.

  2. 02

    Direct

    Define the job target, evidence sources, grounding rules, edit states, and failure behavior.

  3. 03

    Persist

    Save the target, supplied experience, generated suggestion, provenance, and user correction.

  4. 04

    Connect

    Wire generation through authorization, service logic, data, client state, and visible feedback.

  5. 05

    Verify

    Reject unsupported claims; test empty evidence, latency, retries, edits, and saved-state recovery.

  6. 06

    Learn

    Measure corrections and failure patterns before widening the workflow.

Result: a complete, inspectable product behavior—not a disconnected generator demo.

Definition of done

A SaaS release needs proof at three levels.

Use the System Integrity overlay when repository count, integrations, money, regulated data, or agent autonomy raises the consequence.

Layer

  • Schema and migrations preserve integrity
  • Services enforce domain rules
  • APIs authorize every action
  • UI represents all material states

Seam

  • Contracts agree across callers
  • Retries cannot duplicate effects
  • Failure does not corrupt state
  • External results reconcile locally

Operation

  • Release is observable and reversible
  • Secrets and environments are separated
  • Support and recovery paths exist
  • Live behavior is reviewed after change
Add assurance

Does failure affect money, regulated data, or external systems?

Add the System Integrity overlay to distinguish implementation from integration, deployment, and safe activation.

Open System Integrity →