📌 Executive Summary & Overall Assessment

Key

📋 Summary

Midshift is a well-conceived, carefully engineered campaign-production tool for retail marketing teams and their agencies. Its code is cleaner, better documented and more thoroughly self-checked than is typical for a young, single-owner product, and its most distinctive features — reading copywriters' Word decks, matching designers' files to adverts by name, and building tracking links from one template — are well tested. As delivered, however, it carries two critical security exposures that are cheap to fix but must be fixed before any acquisition completes: database permission rules that, as written in the repository, let any signed-in user make themselves an administrator, and a web-framework version with published critical vulnerabilities. Beyond those, the largest risk is not technical but human: the code, the decisions, the operation of each client deployment and the intellectual property all sit with one person, and the git history has been squashed so that how the product was built cannot be inspected. A buyer is acquiring a sound foundation with a short, well-defined list of urgent repairs and a significant dependency on the founder's transition.

🎯 Rating

🔴 ●●○○○ Overall: 2 / 5 — Red (as delivered). The asset's underlying engineering would merit an Amber 3; it is held at Red by a Critical privilege-escalation path, a critically vulnerable framework pin and a bus factor of one. The first two are small (S-effort) fixes; with them made and verified on every live deployment, the overall position moves to 3 / 5 Amber within about 30 days.

🔍 Findings

⚖️ Verdict

Technically, Midshift is a coherent modular monolith on a mainstream stack (Next.js, React, TypeScript, Supabase, Vercel, Resend) that a competent web team could take over. Domain logic is centralised in small, tested functions; type-checking and linting are strict and clean; the team has turned its own lessons into automated guard rails. The weaknesses cluster in one place — the path by which data is written and permissions are checked — which is the least tested part of the system and where every serious security finding sits. Operationally, each client is a separate, hand-configured deployment with hand-applied database migrations, which suits a small number of high-touch clients but not a scalable SaaS thesis. Commercially, the code is owned by an individual, and there is no history to verify authorship or delivery pace.

📊 Scorecard

Unweighted mean of module ratings: 2.8. The overall rating is set below the mean deliberately, because Critical security findings and key-person risk dominate a buyer's exposure regardless of average quality.

🚩 Top 5 risks

💎 Top 5 strengths worth paying for

1. Distinctive, well-tested domain IP. The copy-deck parser (85% covered against a 22-unit regression deck), the shared filename-to-unit matcher (98%), and the single UTM builder (100%) encode hard-won workflow knowledge competitors would have to rediscover. (Modules 1, 4, 7)
2. Engineering discipline turned into automation. Strict TypeScript, zero lint warnings, low duplication, and bespoke guard-rail tests (every write's result must be read; every queried column must exist; every route must have a harness twin; no client identity may be committed). (Modules 5, 10)
3. Exceptional written rationale. Architecture, API reference (82 of 83 routes) and a decision log explain why things are as they are — rare for a product of this size, and the main mitigation for the key-person risk once corrected for drift. (Module 12)
4. Clean, low-cost stack and licensing. Mainstream, easily staffed technologies; only three runtime vendors; no strong-copyleft licences in the dependency tree; no AI-provider dependency or cost. (Modules 2, 8, 13)
5. Data isolation by design. One database per client means no cross-tenant leakage risk and a straightforward story for enterprise data-protection reviews; white-labelling is built in as data. (Modules 1, 3)

❓ What could not be assessed — follow-up questions and access requests

🗺️ Recommended next steps for a buyer

🔒 Before signing (conditions precedent)

• Owner to fix and deploy, to every client: restrict users updates to non-privileged columns (and stop trusting sign-up metadata for role); upgrade Next.js to ≥ 16.4; evidence both on live systems.
• Obtain items 1–3 and 6 above; obtain a deed of IP assignment and originality warranties.
• Agree a paid founder transition and retention period.

1️⃣ First 30 days

• Close the High security findings: approval self-grant and approver removal, stored XSS in the brief, open redirect, unescaped e-mail HTML, QA harness routes in production builds; add rate limiting to auth endpoints.
• Add Dependabot/Renovate, npm audit, CodeQL/Semgrep and secret scanning to CI; require PR review on main.
• Add error tracking (e.g. Sentry) and alerts for cron failures and e-mail errors.
• Second engineer completes a shadowed deploy, migration and incident drill.

2️⃣ 31–60 days

• Route-level integration tests against a local Supabase for authorisation and the six most complex handlers; RLS tests for every user-writable table.
• Move all browser-side writes behind API routes (or prove RLS enforces the same rules); introduce transactions (Postgres functions) for multi-row writes.
• Automate migrations and record per-deployment schema state; correct the fresh-install documentation; replace xlsx.

3️⃣ 61–90 days

• Run the journey suite in CI; stand up a shared staging environment.
• Refactor the fat route handlers behind tests; paginate the capped queries; replace persisted long-lived signed URLs.
• Decide the tenancy strategy: if the thesis is SaaS scale, scope the move to multi-tenant or to automated per-tenant provisioning (infrastructure-as-code).
• Rewrite handover and process documentation for a human team; move the debt register into an issue tracker; delete dead code and orphaned schema.

🧾 Evidence

Synthesised from module files 01–13 in this folder. The highest-severity findings were independently re-verified while compiling this summary:

• supabase/baseline.sql:1044–1046 (users update policy, no column restriction), :940–950 (handle_new_user reads role from metadata); src/lib/api-auth.ts:50, 123 (admin check reads users.role); no trigger or column grant on users found in baseline.sql or supabase/migrations/.
• npm audit / npm audit --omit=dev (24 / 11 vulnerabilities); src/app/icon.tsx:1,16, src/app/apple-icon.tsx:1,14 (ImageResponse).
• src/app/api/campaigns/[id]/members/[memberId]/route.ts:25–48 with src/lib/discipline.ts:58 (self-grant of approver discipline).
• src/lib/brief.ts:187–195 returns HTML-looking text unescaped; brief-view.tsx:557 renders it; campaign PATCH accepts brief_text without sanitizeBriefHtml.
• src/app/qa/layout.tsx:11 gates pages only; src/app/qa/{api,state,reset}/route.ts have no environment check.
• git log --all → one commit; LICENSE line 1.

⚠️ Risks

See Top 5 risks above; full registers are in each module's Risks section.

✅ Recommendations

See Recommended next steps above. Priority order: conditions precedent → 30 → 60 → 90 days.