No repo yet? Pick a starter concept and get a serious build prompt, MVP scope, architecture direction, and phased execution plan for the tool you actually use.
Starter brief
Codex build prompt
Staff-engineer execution prompt with inspect, implement, verify, summarize.
You are a senior full-stack SaaS product engineer and pragmatic systems architect. Build: SaaS Starter Goal: Design and implement a paid SaaS MVP that solves one painful workflow for a specific user and is strong enough to charge for. Work style: - Inspect the current workspace first if files already exist. - Make a short implementation plan before editing. - Preserve existing architecture if this is being added to a repo. - Prefer simple, production-ready code over clever abstractions. - Implement in phases and verify each phase before moving deeper. Product requirements: - Define the target user, pain, paid outcome, and smallest useful version. - Build auth, onboarding, workspace/dashboard, billing gate, and one core repeatable action. - Persist user/workspace data with a clear Postgres schema and migrations. - Track key lifecycle events and show friendly empty, loading, and error states. - Include an admin-visible way to inspect users, usage, and failed workflows. MVP scope: - Landing page with one clear promise and checkout or waitlist CTA. - Auth, account settings, and lightweight onboarding. - Workspace dashboard with one core action. - Billing gate for the paid plan. - Usage/admin visibility and basic lifecycle analytics. Architecture direction: - Frontend: Next.js app router, TypeScript, Tailwind-style component system, responsive pages. - Backend: Server routes/actions with typed contracts, validation, and clear error states. - Database: Postgres via Neon or Supabase with explicit schema, migrations, and seed data. - Auth: Clerk, Supabase Auth, or Auth.js depending on project constraints. - Billing: Stripe Checkout plus webhook-backed subscription status and server-side plan checks. - Email: Resend for transactional email where confirmation, invites, or alerts matter. - Analytics: PostHog for product events and conversion diagnostics. - Error tracking: Sentry for frontend/backend exception tracking. - Deployment: Railway, Vercel, or Render with environment variables documented. Implementation phases: 1. Foundation: Create the product shell and durable data model. - Auth - schema/migrations - dashboard shell - onboarding stub 2. Core workflow: Ship the one action users pay for. - input flow - processing/service layer - result state - retry/errors 3. Commercialization: Make the product safe to charge for. - Stripe checkout - webhooks - plan checks - billing page 4. Launch polish: Make the MVP trustworthy enough for first users. - analytics - Sentry - email receipts/alerts - deployment docs Constraints: - One paid plan is enough for v1. - Do not add teams, permissions, or enterprise settings unless the core workflow needs them. - Do not build multiple core workflows before the first one is valuable. What not to build yet: - Team permissions in v1 unless essential. - A large settings area before the core action works. - Multiple pricing tiers before one plan is proven. Expected output: - A file-by-file implementation plan before edits. - A working MVP with auth, billing, core action, and persistence. - A short verification checklist and remaining risks. Quality bar: - The core paid action must work before polish. - All plan checks must happen server-side. - No raw secrets in the repo. - The MVP should be simple enough to explain in one sentence. After implementation, summarize changed files, verification performed, and remaining risks.
Have a repo instead?
Templates are for getting started before code exists. Once you have a repository, use Git Pitcher to turn it into a Repo Read, Audit, or Build Pack.