Cursor is not magic. It is a force multiplier on a process you already have. After shipping seven B2B SaaS MVPs in 14-21 day windows, my workflow is stable: Composer for vertical slices, Chat for debugging, and a.cursorrules file that stops the model from improvising auth.
Composer: Feature Scaffolding
I scope one vertical slice per Composer session: “Stripe checkout + webhook ledger + subscription row update.” I attach @codebase and the relevant Supabase migration. I reject broad prompts like “build billing.” Composer output gets reviewed before I accept | especially imports and env usage.
Chat: Debugging and Diffs
When something fails in CI or Sentry, Chat gets the stack trace + file. I ask for root cause, not a rewrite. Chat is better at narrowing than at greenfield architecture.
.cursorrules (Excerpt I Actually Use)
# The MVP Guy | client SaaS
- Next.js App Router, TypeScript strict, no any
- Server Components by default; client only for interactivity
- Supabase: createServerClient on server; never expose service role
- Never disable RLS; never skip Stripe webhook signature verify
- PostHog for product events; GA4 pageviews onlyTask Breakdown
Day 1-3: schema + RLS + auth. Day 4-7: core B2B feature. Day 8-10: Stripe. Day 11-12: admin + emails. Day 13-14: deploy, analytics, hardening. AI fills implementation inside each box | it does not move the boxes.
What I Reject From Composer
Whole-repo refactors in one pass. New dependencies without justification. Client-side service role keys. “Temporary” RLS disables. Any auth flow that stores sessions in localStorage without httpOnly cookies. Composer is powerful enough to ship garbage at senior-engineer speed | guardrails matter.
Need this shipped in production, not just in a blog post? Start your MVP.
