Workflow · PM · Dev · Deployment

A clean way to ship, review, and deploy.

Three focused views: how the PM runs the week, how the developer reviews AI + local code, and exactly how each deployment to production happens — one-time setup, then the recurring cycle.

AI Tools

Local Code

Git / GitHub

Human (PM)

Human (Dev)

One-time

Project Manager — Weekly Flow

The PM owns the cadence and the loop. They translate ideas into tasks, route work to the right person or tool, QA every build before release, and feed proactive suggestions back into the roadmap.

A week in motion

Sprint kickoff & task routing

Review last week, lock this week's scope, and split each task by lane — UI in Lovable (you), backend / complex work in Cursor (dev), async batch jobs to Codex. Every task gets a GitHub issue with the lane labelled so nothing overlaps.

Teams call GitHub Issues

PM Daily

Async standup & PR tracking

Short daily written update: shipped, in flight, blocked. PM watches the PR queue and unblocks anything stuck — without forcing meetings.

Teams thread GitHub PRs

Ideas drop — 3 to 5 proposals

A short written doc with new feature, UX, performance, or automation ideas. Each comes with rough effort, impact, and a recommendation. You pick what enters the roadmap.

Notion / Doc

PM QA

QA, demo & weekly summary

Manual QA pass on staging before each release — happy paths, edge cases, regression. End of week: live demo of what shipped, short retro, and a written summary for the record.

Staging URL Weekly report

Developer — Code Flow

The dev is the safety net and accelerator. Lovable, Cursor, and Codex all feed into the same GitHub repo. Every PR flows through the dev's review before touching production.

How a feature ships

AI · Lovable Auto-sync

You build UI in Lovable

You design screens and quick features in Lovable. Two-way GitHub sync auto-commits every change to a lovable-staging branch — no manual export needed.

Lovable lovable-staging branch

Local · Cursor Dev review

Dev pulls locally & polishes

Dev pulls lovable-staging into Cursor, reviews the diff line by line, fixes edge cases, adds error handling, tightens performance — the 30% AI usually doesn't finish.

Cursor (local)

AI · Codex Local · Cursor Parallel

Parallel feature work

While the dev polishes locally, Codex runs bigger backend tasks in the background ("refactor auth module", "add pagination") in its own cloud sandbox — and opens its own PR. Two or three features in flight at once.

Codex (cloud) Cursor (local)

Dev review Multi-agent

PR review — single or multi-agent

Every PR — yours, Codex's, or the dev's — gets reviewed before merge. Routine ones reviewed by the dev directly. For critical PRs, run a parallel Claude + Codex + Cursor review on the same diff to catch what one tool would miss.

GitHub PR Claude Codex

CI / CD Merge

Auto-checks → merge → staging deploy

GitHub Actions runs lint, type-check, and tests. Anything failing blocks the merge. Once green and approved, PR merges into main and auto-deploys to staging for QA.

GitHub Actions

Deployment — Setup & Cycle

Two parts. First, the one-time setup: disconnect Lovable from production, clone the database to staging, and point Lovable at the new staging Supabase. After that, every release follows the same short recurring cycle — code, DB migrations, edge functions, secrets.

Note on cloning the database

The Supabase production database needs to be clone to staging using the CLI dump + restore method. Schema, data, RLS policies, database functions, and triggers all migrated correctly.

Edge functions and secrets do not auto-clone — they live in your Supabase project config, not in the database. They must be deployed separately to the staging project using supabase functions deploy and supabase secrets set. Same applies for every future migration: code, DB, edge functions, and secrets are four separate deploy steps.

One-time setup Run once

One-time Lovable

Disconnect Lovable from production Supabase

In the Lovable project settings, remove the existing production Supabase connection. This stops any new prompt-generated change in Lovable from accidentally writing to the live database.

Lovable settings

One-time Supabase

Create the staging Supabase project

Create a fresh Supabase project named clearly as staging (e.g. crm-staging). Note its project ref, anon key, and service role key — these become the new credentials for everything downstream.

Supabase Dashboard

One-time CLI

Clone production → staging database

Use the Supabase CLI to dump production (roles, schema, data — in that order) and restore into staging. RLS policies, database functions, and triggers come over with the schema dump.

One-time Edge fns

Deploy edge functions & secrets to staging

Edge functions and secrets do not migrate with the database. Deploy them to the new staging project explicitly. Use the --project-ref flag so they land on staging, not production.

One-time Safety

Disable destructive extensions on staging

Right after cloning, disable pg_cron and pg_net on staging — otherwise scheduled jobs will fire real emails, payments, or webhooks against your live integrations. Re-enable only the ones staging actually needs.

Database · Extensions

One-time Lovable

Connect Lovable to staging Supabase

In Lovable, add the new staging Supabase URL and anon key as the project's database connection. From this point on, every change Lovable makes writes to staging — production stays untouched until a deliberate release.

Lovable settings

One-time Cursor

Update local & app environment variables

Update .env.staging in the codebase with the new staging Supabase URL, anon key, and edge function endpoints. Cursor + Codex now build against staging by default. Production keys stay in .env.production, only used at release time.

.env.staging GitHub Secrets

Every release — recurring cycle Every deploy

Code CI / CD

Deploy application code → production

After QA passes on staging, merge the release branch into main. GitHub Actions runs final checks and deploys the production build (Vercel / hosting of choice). Same code that ran in staging, just pointed at production env vars.

GitHub Actions

Database CLI

Push database migrations → production

Any schema or RLS changes made on staging during the sprint are captured as migration files. Push them to production with the Supabase CLI — versioned, reviewable, reversible.

Edge fns CLI

Deploy edge functions → production

Any new or updated edge function is deployed to production with the same command used on staging — just pointed at the production project ref.

Secrets CLI

Sync secrets → production (when changed)

If a secret changed during the sprint (new API key, rotated token), set it on production. Skip this step on releases that don't touch secrets.

Verify PM

Smoke test on production

PM runs a 5-minute smoke test on live: key user journeys, recent changes, any edge function endpoints touched. If anything's off, the dev rolls back the deploy or pushes a hotfix.

Production URL Slack release note