Read Two Engines first for the why. This is the how.

Create an Explore Folder

Exploration code lives separately from production code. This isn't just organisation — it's permission to be messy.

your-project/
├── src/
│   ├── components/     # Production code
│   ├── app/            # Production routes
│   └── ...
├── explore/            # Engine 1 lives here
│   ├── checkout-flow/
│   ├── new-dashboard/
│   └── pricing-page/
└── ...

Add explore/ to your .gitignore if you want. Or keep it — it's useful documentation of what you tried.

Define Your Exploration Prompt

The prompt for Engine One is different from Engine Two. You're optimising for speed and visual feedback, not maintainability.

# Engine 1: Exploration Mode

You're helping me explore UI concepts quickly.

Priorities:
- Speed over perfection
- Visual clarity over code quality
- Self-contained files (inline styles OK)
- Make it look real — use realistic content

Don't worry about:
- Component reusability
- Production patterns
- Performance optimisation
- Tests

I want to feel the interface, not ship it.

This context lets AI generate fast without over-engineering. The output won't be production-ready, and that's the point.

Explore in Variations

Don't iterate on one design. Generate multiple directions and react to them.

explore/
└── checkout-flow/
    ├── v1-single-page.tsx      # Everything on one screen
    ├── v2-stepped-wizard.tsx   # Multi-step with progress
    ├── v3-sidebar-summary.tsx  # Persistent order summary
    └── notes.md                # What I learned

Three variations in an hour beats three weeks of iteration on one guess.

Document What You Learn

The code is throwaway. The decisions aren't. Capture them.

# Checkout Flow Exploration

## Decision: Stepped wizard (v2)

### Why not single page (v1)?
- Felt overwhelming with our product options
- Users didn't know where to start

### Why not sidebar summary (v3)?
- Great on desktop, awkward on mobile
- Summary took too much horizontal space

### What matters in v2:
- Progress indicator is critical (users asked "how long?")
- Back button must preserve state (users panicked)
- Mobile: stack steps vertically, not tabs

### What doesn't matter:
- Exact spacing (engineering can refine)
- Animation timing (nice to have)
- Button colours (use system default)

Hand Off to Engine Two

The handoff isn't "build this." It's "here's what we learned, here's what matters."

# Checkout Flow — Ready for Production

## Validated direction
Stepped wizard with progress indicator.
Exploration code: explore/checkout-flow/v2-stepped-wizard.tsx

## Critical (preserve these)
- Progress indicator showing step X of Y
- Back button that preserves form state
- Error messages inline, not toast

## Flexible (engineering discretion)
- Exact step transitions
- Spacing and layout details
- Loading state implementation

## Constraints (from our hard stops)
- Each step component: max 100 lines
- Max 8 props per component
- No loading states inside step components

## Reference
See /articles/hard-stops for production constraints.

"The handoff isn't code. It's clarity about what matters and what doesn't."

Engine Two: Production Mode

Different prompt, different priorities. Now engineering takes over.

# Engine 2: Production Mode

You're building production components.

Hard constraints:
- Primitive components: max 50 lines
- Composed components: max 100 lines
- Feature components: max 200 lines
- Max 8 props, max 1 callback, max 2 booleans
- No loading/error states inside (parent's job)
- No nested object props

Reference the exploration code for intent,
but rebuild from scratch following constraints.

See Build Hard Stops for Your Team for the full constraint system.

Quick Reference

Engine 1: Explore

→ Lives in /explore
→ Speed over quality
→ Multiple variations
→ Product owns it
→ Output: validated decisions

Engine 2: Produce

→ Lives in /src
→ Quality over speed
→ Constraints enforced
→ Engineering owns it
→ Output: shippable code