§ 00 — The playbook

Amble → Sprint → Sail is a decision system.

AI makes it easier to produce software. That increases the need for judgment, constraints, distribution, evidence, and honest stop rules. This playbook is how Sprinter Studio turns an idea into the next responsible decision.

Work can advance, move backward, pause, or stop at every stage. The method is useful only when the label changes with the evidence.

The four rules underneath the stages

A stage is a confidence label.

Amble, Sprint, and Sail describe what has been learned and what decision is next. They are not badges of company maturity.

The smallest useful test wins.

The purpose of a Sprint is to answer a consequential question with the least code, capital, and attention required — not to make the demo look complete.

Humans remain accountable.

AI agents can research, draft, code, test, monitor, and operate bounded tasks. People own safety, product judgment, customer relationships, and consequential decisions.

Stopping is a valid output.

A fast, well-instrumented invalidation is more valuable than keeping a weak property alive to inflate the portfolio.

Phase 1: Amble

Question before building

Amble is structured exploration. The job is to understand the user, workflow, stakes, buyer, alternatives, and path to demand. Research can narrow the search, but direct operator and buyer access matters more than a polished market-size slide.

Useful activities

→ Observe or map the current workflow and its exceptions
→ Interview users, buyers, partners, and people who tried alternatives
→ Define the value, risk, owner, and distribution hypothesis
→ Test demand with a conversation, service, prototype, or manual concierge flow
→ Write the failure conditions before writing the product scope

Gate 1: deserves a bounded Sprint

A named user and painful job, not a broad market category
Direct access to people who experience or buy around the problem
A credible distribution path that does not depend on generic virality
A falsifiable value and monetization hypothesis
A bounded test that can answer the next question without a full product
An explicit reason the experiment deserves attention over current commitments

Phase 2: Sprint

Build the smallest credible test

Sprint is focused implementation around one question. AI agents can accelerate research, scaffolding, coding, content, tests, and operations, but the test still needs a human owner, real users, explicit safety boundaries, and evidence that determines what happens next.

Useful activities

→ Define the workflow, inputs, outputs, owner, and human-review points
→ Build only the path required to test the primary hypothesis
→ Instrument usage, errors, quality, latency, and value signals
→ Put the system in front of the intended user or buyer
→ Record what is still manual, fragile, unsafe, or unproven

Gate 2: evidence justifies continued operation

One primary question and explicit acceptance criteria
A real workflow, test user, or buyer rather than synthetic feedback alone
Instrumentation for usage, errors, quality, and the intended value signal
Security, access, data handling, and human-review boundaries defined
An owner for the test and a date for the advance, revise, pause, or stop decision
Evidence that determines the next investment before the build begins

Phase 3: Sail

Earn continued investment

Sail begins when a property is live and has a reason to continue. That reason may be revenue, repeated usage, qualified demand, strategic distribution, or reusable internal capability. A live URL alone is not enough.

Useful activities

→ Run the most credible distribution channel consistently
→ Improve activation, retention, willingness to pay, and operating reliability
→ Automate bounded work only after the process is understood
→ Track support burden, quality, risk, revenue, and strategic reuse
→ Revisit whether this work still outranks other uses of attention

Gate 3: responsible continued investment

Repeated use, qualified demand, revenue, strategic reuse, or another explicit reason to continue
A distribution motion with an accountable owner and measurable inputs
Reliability, support, and data risks appropriate to the product’s actual stakes
Economics that justify continued attention, even if the reason is internal leverage rather than SaaS revenue
A resourcing decision based on demand and risk — not an arbitrary MRR vanity threshold
A scheduled review where the work can still be narrowed, paused, archived, or stopped

Every review ends in a decision

“Keep working on it” is not a decision. Each review names the next state, the evidence behind it, the owner, and the next review date.

Advance

The current hypothesis has enough evidence to justify the next bounded investment.

Revise

The problem remains credible, but the audience, workflow, offer, or test must change.

Pause

The opportunity may be real, but timing, access, distribution, capital, or higher-priority work blocks responsible progress.

Stop or archive

The evidence does not justify more attention, or the experiment is no longer strategically useful. Record the learning and release the bandwidth.

What should compound across experiments

The studio should not reuse generic product assumptions. It should reuse the expensive, non-differentiating infrastructure and the quality patterns learned from real work.

Evaluation and quality

Test harnesses, human-review patterns, acceptance criteria, observability, and failure analysis.

Identity and access

Authentication, roles, permissions, audit history, secrets, and least-privilege connector patterns.

Data and integrations

Reliable connectors, ingestion, structured context, queues, retries, and source provenance.

Product operations

Analytics, feedback capture, support workflows, release discipline, documentation, and cost visibility.

Read the method against the actual ledger.

Every entry should make its current stage, evidence, and open questions visible — especially when the next decision is to stop.

View the experiment ledger