Testing a £99 48h “Repo Rescue Brief” for undocumented MVPs — feedback welcome

The scope is clear, but the real test seems to be willingness to pay for certainty. Have any founders actually paid for the brief yet?

As promised — here’s a redacted sample of what’s in the £99 Repo Rescue Brief pack (runbook, architecture map, env/secrets inventory, deploy notes, risk register, fix-vs-rebuild call, and a Day-1 checklist). Fictional project data so I can show the shape without a real client repo:

# Repo Rescue Brief — SAMPLE / REDACTED

SAMPLE / REDACTED — fictional client for illustration. Not a real engagement.

| Field | Value |
| --- | --- |
| Project | PlantPal (habit + plant-care SaaS MVP) |
| Stack | Next.js 14 (App Router), Supabase (Auth + Postgres), Vercel |
| Size | ~2.4k LOC TypeScript/TSX, single service |
| Client contact | founder@example.com |
| Brief date | 2026-03-12 |
| Scope | £99 Repo Rescue Brief (written pack + Loom note) |

A 10–15 min Loom walkthrough would accompany a real delivery. It is not included in this written sample.

---

## 1. Runbook README

### Prerequisites

• Node.js 20.x (LTS)
• pnpm 9.x (corepack enable then corepack prepare pnpm@9 --activate)
• A Supabase project (or local Supabase CLI ≥1.200)
• Vercel CLI optional; GitHub → Vercel is the only documented deploy path

### Setup

git clone <repo-url> plantpal-demo
cd plantpal-demo
pnpm install
cp .env.example .env.local
# fill values from Env inventory below
pnpm db:types          # regenerates supabase/database.types.ts
pnpm dev               # http://localhost:3000

### How to verify it works

1. Open / — marketing landing loads; “Start free” → /signup.
2. Sign up with any email (magic-link in local Supabase; production uses Supabase Auth email).
3. After session: /dashboard lists plants; “Add plant” posts to /api/plants.
4. Toggle a care habit on /dashboard/[plantId] — row appears in care_logs.
5. pnpm build completes with zero TypeScript errors (as of brief date).

### Top 3 setup gotchas

1. NEXT_PUBLIC_SUPABASE_URL must match the project that owns the anon key. Mixing staging URL with production anon key yields opaque 401s on /auth/callback.
2. RLS is on for plants and care_logs. Queries without a user session return empty arrays, not errors — easy to misread as “DB is empty”.
3. pnpm db:types needs SUPABASE_SERVICE_ROLE_KEY. Running it with only the anon key fails silently and leaves stale types; CI does not regenerate types.

---

## 2. Architecture + directory map

Plain English: PlantPal is a single Next.js app. Browser talks to Supabase Auth and Postgres via the Supabase JS client. Server routes under app/api/* use the service role only for webhook-style jobs (none live yet). No separate backend, queue, or worker.

plantpal-demo/
├── app/
│   ├── (marketing)/page.tsx      # landing
│   ├── signup/ · login/          # auth pages
│   ├── auth/callback/route.ts    # OAuth/magic-link exchange
│   ├── dashboard/
│   │   ├── page.tsx              # plant list
│   │   └── [plantId]/page.tsx   # plant detail + habit toggles
│   └── api/
│       ├── plants/route.ts       # GET/POST
│       └── plants/[id]/route.ts  # PATCH/DELETE
├── components/                   # UI (shadcn-style primitives)
├── lib/
│   ├── supabase/
│   │   ├── client.ts             # browser client
│   │   └── server.ts             # cookie-aware server client
│   └── plants.ts                 # shared query helpers
├── supabase/
│   ├── migrations/               # 3 SQL migrations
│   └── database.types.ts         # generated; often stale
├── .env.example
└── vercel.json                   # default; no custom rewrites

Data model (simplified): profiles ←1:N→ plants ←1:N→ care_logs. Auth user id = profiles.id.

---

## 3. Env / secrets / third-party inventory

| Name | Where used | Secret? | Notes |
| --- | --- | --- | --- |
| NEXT_PUBLIC_SUPABASE_URL | client + server | No | e.g. https://plantpal-demo.supabase.co |
| NEXT_PUBLIC_SUPABASE_ANON_KEY | client + server | Public by design | JWT; safe in browser with RLS |
| SUPABASE_SERVICE_ROLE_KEY | pnpm db:types, future admin routes | Yes | sk_test_EXAMPLE_service_role_not_real — must never ship to client |
| NEXT_PUBLIC_APP_URL | auth redirect URLs | No | http://localhost:3000 locally; Vercel prod URL in prod |
| RESEND_API_KEY | referenced in .env.example only | Yes | re_EXAMPLE_not_wired — not used in code yet |
| Vercel project | Hosting | Account-level | Linked to GitHub plantpal-demo |
| Supabase project | Auth + DB | Account-level | Region: eu-west-1 (fake for sample) |

Finding: RESEND_API_KEY and a stub lib/email.ts suggest planned transactional email; nothing calls it. Safe to ignore for Day-1 run, but do not commit a real Resend key “just in case”.

---

## 4. Deploy & ops notes

• Deploy path: push to main → Vercel production. Preview deploys on PRs. No staging project.
• Migrations: applied manually in Supabase SQL editor historically; supabase/migrations/ exists but is not wired into CI. Risk of drift between repo SQL and live schema.
• Logs: Vercel function logs only. No error tracker (Sentry etc.).
• Backups: Supabase free-tier daily backups assumed; no documented restore drill.
• Domains: plantpal-demo.vercel.app only in this sample; custom domain unset.
• Rollback: redeploy previous Vercel deployment from dashboard — works; DB migrations are not automatically reversible.

---

## 5. Risk register

| ID | Priority | Area | Issue | Impact |
| --- | --- | --- | --- | --- |
| R-01 | P1 | Secrets | SUPABASE_SERVICE_ROLE_KEY present in a developer’s laptop .env.local only (good), but also pasted once into a Vercel “Preview” env shared across forks of a template — confirm Preview env is scoped | Full DB bypass if leaked |
| R-02 | P1 | Auth | /api/plants POST checks session cookie but does not re-validate user.id against plants.owner_id on PATCH in one code path (app/api/plants/[id]/route.ts) — relies on RLS as backstop | Cross-user edit if RLS misconfigured |
| R-03 | P2 | Tests | No automated tests. Manual checklist only | Regressions on auth/callback and plant CRUD |
| R-04 | P2 | Ops / SPOF | Single Vercel + single Supabase project; no staging | Any bad migration or env change hits “prod” (the only env) |
| R-05 | P2 | Schema | database.types.ts last generated 2025-11; migrations added watering_interval_days since | Type lies; runtime still works via loose selects |
| R-06 | P3 | Docs | README is default create-next-app boilerplate | Next hire burns hours rediscovering setup |
| R-07 | P3 | Dead code | lib/email.ts + unused Resend env | Confusion about what is live |

---

## 6. Fix / Refactor / Rebuild recommendation

Recommendation: Fix + light refactor — do not rebuild.

The MVP is coherent: one deployable, clear domain model, Auth + RLS roughly right. LOC and coupling fit a small SaaS. A rewrite would discard working product surface for little gain.

Rough next-step scope (post-brief, not included in £99):

| Track | Effort (indicative) | Outcome |
| --- | --- | --- |
| P1 hardening | 0.5–1 day | Owner checks on PATCH; audit Preview env secrets; rotate service role if unsure |
| Types + migrations | 0.5 day | Regenerate types; document “apply migration → pnpm db:types”; optional Supabase GitHub integration |
| Minimal test smoke | 1 day | Playwright: signup → add plant → toggle habit; run on PR |
| Ops hygiene | 0.5 day | Staging Supabase project or at least a staging Vercel env; kill dead email stub or wire it |

Rebuild only if: product direction changes to offline-first / native, or multi-tenant B2B with a different auth model. Neither is indicated here.

---

## 7. Day-1 checklist for the next developer

• [ ] Clone, pnpm install, copy .env.example → .env.local with staging Supabase keys if available
• [ ] Confirm pnpm dev + signup → dashboard happy path
• [ ] Run pnpm db:types and diff database.types.ts — commit if drift
• [ ] Read supabase/migrations/* in order; compare columns to live Table Editor
• [ ] Grep for service_role / createClient — ensure service key never imported in components/ or client bundles
• [ ] Patch R-02: assert owner_id === session.user.id in PATCH/DELETE before relying on RLS alone
• [ ] Delete or quarantine lib/email.ts until Resend is intentional
• [ ] Add a one-page docs/runbook.md (this brief’s §1 is a start) and replace the boilerplate README
• [ ] Skim Vercel env vars (Production vs Preview) with founder@example.com
• [ ] Agree who applies SQL migrations (human vs CI) before the next schema change

---

## Loom note (real delivery only)

In a paid engagement, a 10–15 minute Loom would walk the clone → run path, highlight R-01/R-02 on screen, and narrate the Fix vs Rebuild call. This sample is text-only.

---

End of SAMPLE Repo Rescue Brief. All names, keys, and URLs are invented for illustration.

I reckon the main risk is that a fixed price will attract the repos needing the most rescue. “One repo” could mean a small app or a monorepo with six services and years of drift.

I’d put a hard boundary around the £99 slot — one app, one deployment path and a clear size limit — then quote anything larger separately. A redacted sample brief would also make the 48-hour promise feel more concrete before someone grants repo access. Have you decided where that cutoff sits?