The Build‑or‑Ship Tradeoff Matrix: A Founder’s 6‑Question Framework to Decide What to Build Now vs. Ship as a Workaround

Stop arguing about preferences and ask six crisp questions that map to 'Build', 'Ship workaround', or 'Test first'. Each question is fast to answer and focuses on immediate learning, not long‑term architecture. The goal of the matrix is to move from opinions to observable signals you can collect within days or weeks.

Answer these in order: 1) Is this core to the distinctive value we promise? 2) Can we define the smallest measurable 'good' outcome for users? 3) Can we deliver a credible workaround that won’t damage trust? 4) Will the team be blocked for >4 sprints if we avoid building? 5) Can we test demand with a micro‑MVP or fake door in ≤2 weeks? 6) Do we have a clear monetization or engagement trigger tied to this feature?

Bullets are useful here because you’ll use them during planning. Use the checklist to force yes/no answers (no 'maybe').

bullets':['By default, run question 1–3; stop once you hit a decisive yes that maps to Build or Ship.','Treat “can we test in ≤2 weeks” as the primary gating question for postponing build.','Record one metric per question (e.g., click‑through rate, signups, conversion to paid).'],

Translate the six answers into one of three outcomes with explicit next steps. If the feature is core (Q1) and its definition of 'good' is measurable (Q2), choose Build but with a micro‑MVP scope and a deadline. If it’s not core or the team can ship a safe workaround quickly (Q3 yes), ship the workaround and instrument the behavior. If you can test demand/usage with a micro‑MVP or fake door within two weeks (Q5 yes) — Test first and defer building until you have real user signal.

Each outcome has a standard playbook: build = micro‑MVP spec + breakpoints for refactor; ship workaround = documented UX path + customer communication; test first = experiment design, traffic source, success criteria, and rollback plan. Those playbooks let you ship without creating technical debt or destroying trust.

bullets':['Build playbook: 2‑sprint micro‑MVP, 1 key metric, “stop‑loss” condition if metric < threshold.','Ship workaround playbook: UX copy that sets expectations, telemetry for the workaround, and a sunset plan.','Test first playbook: landing page/fake door, traffic plan, and a follow‑up (email or concierge) for engaged users.'],

Use the right pretotyping pattern for the question you need answered. Fake‑door landing pages and painted CTAs find initial demand fast without engineering. A concierge MVP (manual service behind an interface) tests real willingness to trade time or money. A clickable walkthrough or prototype validates comprehension and retention before a single line of backend code is written.

Examples founders can adapt immediately: 1) Fake‑door pricing: create a pricing page and “Start free trial” button that leads to an email capture and a short survey; 2) Concierge fulfillment: accept a small number of paying customers and deliver manually while logging time and edge cases; 3) Clickable walkthrough: use a prototyping tool to simulate feature flow and run a short user task study to measure task completion and perceived value.

bullets':['Fake‑door: landing page with CTA -> email capture -> “Not live yet” follow‑up asking willingness to pay.','Concierge: manual delivery for 5–10 customers to observe real friction and build product requirements.','Clickable walkthrough: prototype test with 8–10 users to measure comprehension and expected frequency.'],

Fake‑door tests are powerful because they capture behavior instead of promises, but they must be designed to preserve trust. Make the CTA honest enough to avoid deception, segment clicks by source, and follow up quickly with a transparent explanation if you reveal the feature is not available. Use the test only to measure demand signals (clicks, signups, willingness to pay) and not to create false expectations inside your product UI for existing customers.

Practical guardrails: limit visibility of fake doors in production UIs (use landing pages or targeted ads), provide clear follow‑ups that offer early access or refunds, and never take payment for a non‑existent core capability without an explicit pre‑order agreement. These rules let you learn fast without burning credibility — a priority for early founders building a reputation with early adopters.

bullets':['Prefer external landing pages or targeted ads over placing fake CTAs in a live product experience.','Follow up with interested users within 48 hours with an option (waitlist, pre‑order, or early access).','If you plan to accept payments, use explicit pre‑orders and clear terms.'],

Use the included one‑page decision sheet in sprint planning or a weekly PM/Founder sync. Run the six questions, capture yes/no answers, and map to an outcome. Spend 10 minutes per feature: 3 minutes to answer the six questions, 4 minutes to pick the playbook, 3 minutes to assign owners and metrics. That forces speed and prevents paralysis by over‑analysis.

Sample session: bring the top three candidate features, run the matrix for each, and end with a single agreed‑upon next step per feature (build micro‑MVP, ship workaround + telemetry, or run fake‑door test). Export the decision sheet rows into your issue tracker so the outcome and acceptance criteria are attached to the resulting ticket.

bullets':['Print the one‑page sheet (or paste into your planning doc) and require a completed sheet for any feature >3 story points.','Capture one primary metric and one stop‑loss trigger when choosing to build.','Treat “test first” results as binding input for the next decision (do not re‑open build vs ship without new data).'],