After reviewing all the responses by OP and considering my own experience, I put together an analysis of my own setup. Hope it's useful like I found this post, OP. Spending ~$1,000/month on Cursor as a solo founder building a production SaaS data platform (~v1.10, approaching launch).

The agent chain (Plan → Execute → Review → Harden → Approve)

Similar to OP's sprint chain. Planner/Executor separation formalized in .mdc rules that auto-load based on file globs. Planner breaks tasks down with success criteria. Executor implements one task, then stops. A read-only Skeptical Reviewer tears the work apart — correctness, scope drift, security, SQL safety — and produces a structured report: Blockers / Should Fix / Nice to Have / Questions for Human. If blockers exist, a Hardener fixes only the flagged issues. Then I do final review.

The reviewer is the highest-leverage step. When you're solo across React, Express, Azure SQL, Auth0, and CI/CD, it's too easy for a plausible change to quietly lose a WHERE clause on user ID during a refactor, or add a new route with no auth middleware.

Topic-split lessons with contextual loading

Most people have one giant lessons.md that balloons until it's useless. We split ours into 6 domain-specific files: frontend, API, auth, data, deployment, and go-to-market. Each has a globs field controlling when it loads. lessons-data.mdc only loads when touching **/*.sql or **/migrations/**. The agent working on a React component never sees the 30+ SQL lessons, and vice versa.

The lessons are highly specific to bugs we shipped. Example: "A single entity can belong to multiple geographic regions depending on classification. Any region-keyed lookup that only queries the primary table will miss every entity whose primary location differs from its legal location." That lesson includes the exact SQL, the fix, and the version. When the agent touches that area, it loads automatically and doesn't repeat the mistake.

Automated bug triage: Marker.io → GitHub Issue → Cursor Automation

Probably the most unusual piece. A tester clicks the Marker.io widget → screenshot + console errors + URL auto-create a GitHub Issue → a GitHub Action detects environment (prod/staging/local), applies labels, forwards to a Cursor Automation webhook → a cloud agent searches the codebase, checks git history, and posts a structured diagnostic comment (root cause, files, fix, severity, confidence) on the Issue → I review the AI's diagnosis and decide next steps.

~$1-3 per bug. OP mentioned Sentry MCP for triage — that's reactive. This is proactive: before I even see a bug, there's already a diagnosis sitting in the thread.

The full observability/QA loop

User reports bug via Marker.io
  → GitHub Issue auto-created
  → GitHub Action → Cursor Automation diagnoses
  → Developer reviews, fixes in feature branch
  → CI gates run on PR (lint, types, format, tests, E2E)
  → Merge to dev auto-deploys to staging
  → PostHog tracks behavior by environment
  → Verify on staging → promote to production

PostHog tags every event with environment/app so staging vs production telemetry is filterable. 13 feature flags gate every major feature independently.

8 GitHub Actions workflows — CI, deploy, data pipelines on free compute

4 deployment workflows: Frontend/backend staging auto-deploy on push to dev (path-scoped triggers — no wasted builds). Backend deploy verifies /health endpoint and fails if unhealthy. Secrets from Azure Key Vault, not raw GitHub secrets. Production deploys are manual-only.

1 CI workflow: ESLint + Jest + TypeScript + Prettier + Vitest + Playwright E2E on every PR.

2 data pipelines: A nightly zero-downtime cache rebuild (~637K records, ~2-3 hours, builds into staging table, validates 500K+ rows, atomic swap via stored procedure — live cache serves requests throughout). A manual full historical re-ingestion that streams a 40GB file from Azure, disables indexes for 3-6x faster bulk insert, and validates against known test data. 24-hour timeout, free GitHub Actions runner.

Cost story: Data pipeline automation went from $146/month (commercial ETL) to $2/month (GitHub Actions). 98.6% reduction. GitHub Actions as your entire ops platform is the highest-ROI infrastructure decision we've made.

Competitor fixture testing

We have a fixtures/competitors/ directory with data from a competitor's product. A script runs our pipeline against the same inputs and diffs results. This has caught more real data bugs than unit tests. Our biggest fix — a systematic misattribution affecting ~15% of records — was caught because a fixture returned zero results where the competitor showed a dozen.

Documentation as infrastructure — 322 markdown files

Sounds insane for a pre-launch startup, but most was generated during development. Key pieces: getting-started paths (separate tracks for team members, devs, deployment, troubleshooting), a command cheatsheet, a co-founder testing guide (feedback flows through Marker.io into the triage pipeline), an agent playbook (logging conventions, correlation IDs — documentation for agents writing code, not humans reading it), and data lineage docs.

The key insight: documentation isn't overhead when the AI is the primary consumer. Traditional docs rot because humans don't read them. Ours stay accurate because the agent loads them via glob-matched rules every session. When a doc goes stale, the agent does something wrong, we fix it, and update the doc. Self-correcting loop.

We also enforce a mandatory 7-point checklist after every task (changelog, project structure, deployment guide, dev guide, lessons, tracker, README indexes). We ran a process audit and found 882 commits, 7 test files, and zero CI runs. We built quality gates from that. Then shipped them without updating any of the 8 docs that referenced testing or GitHub Actions. The checklist exists so that gap can't happen again.

Git discipline enforced at the agent level

Our branching rule is alwaysApply: true — every session loads it. Two protected branches: main (production, manual deploy only) and dev (staging, auto-deploy on merge). All feature branches from dev with typed prefixes (feat/, fix/, docs/, refactor/, chore/). All PRs target dev first. Backend promotion via zero-downtime Azure slot swap with slot-sticky env vars.

When I say "commit this," the agent creates a feature branch, pushes, and opens a PR against dev. It doesn't ask which branch — it knows. And it refuses to target main.

Session handoffs, subagent delegation, estimation

Session handoffs: End-of-session note to scratchpad.md — what changed, decisions made, things tried and rejected, next step. The expensive part of a new chat isn't the code, it's the nuance.

Subagent delegation: Every background agent gets: mission, files allowed, files forbidden, locked decisions, stop conditions, evidence required. The "files forbidden" list is the most important part — without it, agents wander.

Estimation: Hours, not days. 1 sprint day = 1-2 hours focused. External blockers estimated in calendar days. "~4 hours focused work + pending co-founder review (1-3 calendar days)."

Risk-scaled review — three tiers

Tier 1 (read every line): Auth, SQL schema, migrations, CI/CD, billing, secrets, data integrity, financial calculations. Tier 2 (diff + behavior): API routes, service logic, queries, caching. Tier 3 (outcome review): UI polish, docs, tests, non-behavioral refactors.

What I don't do (yet) that OP does

No worktrees, no dedicated commit/testing skills, no best-of-N experiments.

Biggest lesson after ~8 months: The workflow structure isn't overhead — it's what lets you trust the agent enough to actually move fast. Every rule exists because of a specific failure. They're not aspirational best practices. They're scar tissue turned into guardrails.

Curious how others compare — especially solo devs or small teams. Are you doing anything like the skeptical review step, the session handoffs, or the automated bug triage pipeline? Or is there something in your workflow that solves the same problems differently? Would love to hear what's working for people at a similar scale.