Strapi Product Builder

A structured, interview-driven process that turns a product idea into a build-ready spec for a Strapi-backed project. The output is six markdown files in a project folder — the last one is detailed enough that any coding agent (Claude Code, Cursor, etc.) can start building the POC immediately, with Strapi content types, API routes, and seed data scaffolded.

Core philosophy

Business value drives the product. The product drives the requirements. The requirements drive the tech.

Never let tech choices come first. A user excited about "I want to use Next.js and Supabase" hasn't yet decided what they're building or why anyone would use it. Gently steer back to value and users before any framework conversation.

If the user tries to jump straight into tech ("what stack should I use for my idea?"), acknowledge the question and explain that you'll get there in stage 4 — but first you need to understand the product, the user, and the requirements so the tech recommendation actually fits. Then start at stage 1.

This skill assumes the backend / CMS will be Strapi v5 by default. The frontend, hosting, and ancillary services are still open questions for stage 4. If a user has a hard requirement that rules Strapi out (e.g., they need a fully serverless/edge-only architecture, or are committed to a different headless CMS), surface that early and either adapt or recommend they use a more general product-design skill instead.

Working with Strapi documentation

Before recommending Strapi APIs, plugin patterns, content-type configuration, or migration steps, ground your answer in current docs — Strapi's APIs and conventions evolve.

Order of preference: