Cursor for Solo Founders: From Idea to Production

Solo does not mean you do every job in one chat. It means you need a written team, because there is no other human to catch the thing you skipped.

This is an operating system for a technical (or technical-enough) founder using Cursor: idea, first paid slice, weekly ship and launch loop, production checks. Cursor is the workbench. It is not the company.

The takeaway

One product slice and one distribution slice per week. Agents will over-build. They will not find you customers.

The OS in one line: /positioning then a vertical slice (/auth-system + one paid path + /ship) then a weekly loop (/fix, /ship, /landing-fix or /launch) then /audit and /release when you tag.

Who this is for

You can read a TypeScript diff and run pnpm test. You are building a SaaS, not a demo. You will sit in the review seat.

Who this is not for: a non-technical founder hoping the editor will become the engineering department, or a team that already has a tech lead, QA, and a marketer. Steal pieces. Do not wear the whole costume.

The stack I assume

I will be specific so the commands have somewhere to land:

• Next.js App Router, TypeScript strict
• PostgreSQL, Drizzle or Prisma (pick one in CURSOR.md)
• Session auth (Auth.js / Clerk / equivalent)
• Stripe if you charge
• Vitest, optional Playwright
• Vercel or a box you already understand

If your stack is Rails or a mobile-only app, the shape still holds. The file paths will not.

Fill CURSOR.md before day two. The memory article is that setup. The rules article is the floor under it.

Phase A: Idea and positioning

Write down who it is for and what they already use. /positioning is April Dunford-shaped: alternatives, unique attributes, value, ICP. Run it once. Edit it by hand forever.

What not to build: a design system, a blog engine, a second platform, an AI chat that is not the product. The first slice should force a user through auth and, if you charge, through a payment. Everything else is costume.

/define-brand-voice once, if you will write in public. If you will not, skip it.

Phase B: First vertical slice

Not a framework tour. One path a stranger can finish.

1. Auth that creates a user and a tenant (/auth-system if you are starting from zero).
2. One object the product is about (a project, a document, a monitor). Schema, API, UI, tenant tests. /ship or the hand pipeline.
3. If you charge: Checkout + webhook + a gate on that object (/stripe-billing). Do not build a customer portal UI by hand if Stripe Portal exists.
4. Deploy. A URL you can send.

Definition of done for the slice: lint, test, build, a tenant test, a webhook signature check if money moves. Not "the dashboard looks busy."

Complexity L ideas ("workspace sharing with SSO and audit log") do not belong in week one. /feature-spec them onto a later week.

Phase C: The weekly loop

A week that works:

Two slices in a week is a fantasy unless both are tiny. One product slice plus one distribution artifact is enough.

/launch is for a date on the calendar, not for a Thursday when you feel behind. A launch kit you do not send is clutter in docs/marketing/.

Phase D: Production

Before you take money from a stranger:

• /audit on API routes and queries
• Webhook signature + idempotency
• Backups you have restored once
• An error shape clients can branch on
• /release notes for anything you already shipped to a human

After you take money: /sre-incident is for when it is actually down. /compliance-audit is for when you have a real question, not a badge.

You still need logging and a place you will look when a user emails you. Agents do not replace that.

Hats and which command owns them

If you install only the engineering kit, the last two rows are you, in a text editor, without a playbook. That is a valid choice. The Kit Picker is the yes/no version. The Marketing Kit is the paid version of Thursday and Friday.

Limitations

Cursor will not find you customers. A polished /launch thread sent to nobody is still nobody.

Agents will over-build. They would like to add roles, tags, and a settings IA. Your job is the out-of-scope list.

This OS assumes you can reject a diff. If you cannot, stop and learn the stack on a smaller surface.

The build story is how this OS got packaged. The install docs are how it lands in a repo. Use the kit, or copy the weekly table onto a sticky note. The sticky note is enough if you fill it in.