From Validation to Delivery: A Best‑Practice Guide for Startup Pressure Test and gstack

Problem Overview

The greatest risk is not AI writing buggy code, but AI obediently turning a fundamentally bad idea into a polished product that no one wants.

Two AI‑assisted tools

codex-startup-pressure-test-skill

Acts as an early‑stage filter that interrogates a startup idea from an investor/YC‑interviewer perspective before any code is written.

Core questions:

Is the problem painful enough?

Who are the earliest adopters?

What are the current alternatives?

What is the core hypothesis to validate?

Can a two‑week MVP prove or kill the hypothesis?

Default compact output includes Verdict, Scorecard, Core Assumption, Fatal Flaws, Problem Reality, Competition, First 10 Customers, and MVP. It does not manage downstream design, engineering, QA, or release.

gstack

Garry Tan’s open‑source Claude Code workflow that splits AI into role‑based agents (CEO, Designer, Engineering Lead, QA, Release Engineer, etc.) and runs a full product‑engineering pipeline.

Core pipeline:

Think → Plan → Build → Review → Test → Ship → Reflect

The most relevant skill for idea validation is /office-hours, which mimics YC Office Hours by asking six forcing questions about real‑world need, existing alternatives, narrowest slice, future fit, etc., and then produces a design doc for downstream skills such as /plan-ceo-review, /plan-eng-review, /qa, and /ship.

Reference repository: garrytan/gstack and gstack/docs/skills.md.

Core Differences

Nature : Startup Pressure Test is a single skill that filters ideas; gstack is a complete AI product/engineering workflow.

Best scenario : Pressure Test for early, quick direction judgment; gstack for ideas that already have traction and need planning, design, implementation, QA, and release.

Thinking style : Pressure Test uses investor/YC interview interrogation; gstack uses product‑team role progression.

Output : Pressure Test returns a compact verdict and scorecard; gstack returns design docs, architecture reviews, code reviews, QA reports, and release processes.

Interaction depth : Pressure Test is short and direct; gstack involves longer, multi‑round interactions.

Suitable users : Pressure Test for founders, solo developers, and content planners needing rapid validation; gstack for founders, engineering leads, and AI‑first teams ready to build.

Pros and Cons

Startup Pressure Test – Pros

Excels at killing bad ideas by asking brutal questions about pain, early adopters, differentiation, and two‑week MVP feasibility.

Compact output keeps decision cost low; multiple ideas can be batch‑run.

Works for content teams to evaluate columns or product ideas as “startup ideas”.

Startup Pressure Test – Cons

Does not handle downstream execution (design, engineering, QA, release).

Can be overly negative and risk discarding markets that need time to mature.

Output quality depends on input quality; vague inputs yield generic results.

gstack – Pros

Role‑based division of labor ( /office-hours, /plan-ceo-review, /plan-eng-review, /review, /qa, /ship) turns an idea into a full product pipeline.

Better for complex projects and team collaboration; structures responsibilities that would otherwise be scattered. /office-hours mimics real YC conversations, surfacing hidden pains behind user requests.

gstack – Cons

Heavier system with higher startup cost; not ideal for quick “should I build?” checks.

If the initial validation is weak, gstack may push a bad idea forward.

Requires disciplined process adherence; using a single skill out of context loses its contextual advantage.

Decision Guidance

If you have only a single idea and need to validate pain and core hypothesis, use Startup Pressure Test.

If you have 3‑5 candidate directions, run Startup Pressure Test to discard weak ones.

If you already have real user feedback, run gstack /office-hours to turn feedback into a design doc.

If you have decided to build an MVP, run gstack /plan-ceo-review and /plan-eng-review for scope and architecture review.

If you have code changes and need bug finding, run gstack /review + /qa.

If the team wants a long‑term process, combine both: filter with Pressure Test, then deliver with gstack.

Recommended Combined Workflow

Chain the two tools in the following order:

Startup Pressure Test
  ↓
Keep the worthwhile direction
  ↓
gstack /office-hours
  ↓
gstack /plan-ceo-review
  ↓
gstack /plan-eng-review
  ↓
Build → Review → QA → Ship

Step 1 – Run Startup Pressure Test to obtain Core Assumption, Fatal Flaws, Problem Reality, Competition, First 10 Customers, and a two‑week MVP. If the verdict is “Weak” or “Pivot required”, iterate on the idea before proceeding.

Step 2 – Feed the output into /office-hours to continue probing and produce a design doc.

Step 3 – Hand the design doc to /plan-ceo-review (product scope) and /plan-eng-review (architecture, data flow, test boundaries), then to /review, /qa, and /ship for implementation.

Sample Prompts

Prompt 1 – Direction Filtering

Use $startup-pressure-test to brutally pressure‑test the following startup idea:

Idea:
An AI tool that automatically cuts long product demo videos into short clips suitable for X/LinkedIn.

Target customers:
Solo developers, small‑team founders, people who need to publish frequent product updates.

Current alternatives:
They manually edit with CapCut / Descript, or skip publishing because it’s tedious.

Desired user action / payment:
Monthly subscription; upload a video and receive three publish‑ready short clips.

Please output:
1. Core Assumption
2. Fatal Flaws
3. Problem Reality
4. Competition
5. First 10 Customers
6. 2‑week MVP
7. Strong / Weak / Pivot required verdict

Prompt 2 – Hand‑off to gstack

I have already run Startup Pressure Test and obtained the following results:

- Core Assumption: <paste core assumption>
- Fatal Flaws: <paste top 3 fatal risks>
- Problem Reality: <paste reality assessment>
- Competition: <paste current behavior and competitors>
- MVP: <paste two‑week MVP suggestion>

Please run gstack /office-hours and continue probing:
1. Which premises still don’t hold?
2. What is the narrowest, most valuable slice to build first?
3. What user evidence must be gathered next?
4. If we move to MVP, how should the design doc be written?

Do not jump straight to implementation. First clarify the direction.

Application for Content Teams

Treat a column or article topic as a startup idea and run Startup Pressure Test to answer: target audience, pain points, current solutions, click motivation, sharing or payment incentives, and a two‑week validation plan.

When the topic passes, switch to gstack to flesh out a series, course, community, or tool using /office-hours, /plan-ceo-review, /plan-design-review, and /review / /qa for release checks.

Final Recommendation

Startup Pressure Test decides “should we build?”; gstack decides “how to build it”.

The most reliable strategy is to use the filter first, then feed the validated direction into the full delivery pipeline. This prevents the most expensive mistake—building something that no one wants—by catching it as early as possible.