📌 Midshift — Technical Due Diligence
📌 Midshift — Technical Due Diligence
🔒 Confidential. This assessment describes unpatched security weaknesses in a live product and evaluates proprietary code. Keep this repository private and share it only with people who are party to the transaction.
A structured technical due diligence of Midshift, a campaign-production platform for retail marketing teams and their agencies (Next.js · React · TypeScript · Supabase · Vercel). It was carried out on 2026-10-07 against the source supplied for audit (single commit 3789df6, 2026-10-06), for a party considering acquiring, investing in or taking over maintenance of the software.
Key
| Rating | Severity | Status |
|---|---|---|
| 🟢 Green — 4 to 5 | 🔴 Critical | ✅ Yes |
| 🟡 Amber — 3 | 🟠 High | ❌ No |
| 🔴 Red — 1 to 2 | 🟡 Medium | ◐ Partial |
| ●●●○○ — score out of 5 | ⚪ Low |
⚖️ Verdict
🔴 ●●○○○ Overall: 2 / 5 — Red as delivered; 3 / 5 Amber once two small Critical fixes are deployed and verified.
A well-conceived, carefully engineered product with distinctive, well-tested domain logic, held back by two cheap-to-fix but Critical security exposures and by a bus factor of one. Read the executive summary first.
🚩 Top risks
| Risk | Severity | |
|---|---|---|
| 1 | Any signed-in user can make themselves an administrator (database permission rule) | 🔴 Critical |
| 2 | Web framework pinned to a release with published critical vulnerabilities | 🔴 Critical |
| 3 | Code, operations and IP concentrated in one person; history squashed | 🔴 Critical |
| 4 | Sign-off integrity can be undermined from inside a job | 🟠 High |
| 5 | Riskiest code is the least tested; failures are invisible | 🟠 High |
💎 Strengths worth paying for
- Distinctive, well-tested domain IP — copy-deck parser, filename matcher, single tracking-link builder
- Engineering discipline turned into automation — strict types, clean lint, bespoke guard-rail tests
- Exceptional written rationale behind decisions
- Clean, low-cost stack and licensing; only three runtime vendors
- One database per client — strong data isolation by design
📊 Scorecard
| # | Report | Rating | RAG |
|---|---|---|---|
| 01 | Product & Domain Overview | ●●●●○ 4 / 5 | 🟢 Green |
| 02 | Technology Stack & Codebase Complexity | ●●●○○ 3 / 5 | 🟡 Amber |
| 03 | Architecture & Design | ●●●○○ 3 / 5 | 🟡 Amber |
| 04 | Domain Model & Business Rules | ●●●○○ 3 / 5 | 🟡 Amber |
| 05 | Code Quality & Standards | ●●●●○ 4 / 5 | 🟢 Green |
| 06 | Technical Debt & Maintainability | ●●●○○ 3 / 5 | 🟡 Amber |
| 07 | Testing & QA | ●●●○○ 3 / 5 | 🟡 Amber |
| 08 | Dependencies & Licensing | ●●○○○ 2 / 5 | 🔴 Red |
| 09 | Security & DevSecOps | ●●○○○ 2 / 5 | 🔴 Red |
| 10 | Source Control, CI/CD & Development Practices | ●●●○○ 3 / 5 | 🟡 Amber |
| 11 | Delivery Metrics & Key-Person Risk | ●○○○○ 1 / 5 | 🔴 Red |
| 12 | Documentation Review | ●●●○○ 3 / 5 | 🟡 Amber |
| 13 | Integrations | ●●●○○ 3 / 5 | 🟡 Amber |
| 14 | Executive Summary & Overall Assessment | ●●○○○ 2 / 5 | 🔴 Red |
The index lists each report's top risk.
📖 How to read the reports
Every report follows the same structure: 📋 Summary (plain English) · 🎯 Rating · 🔍 Findings · 🧾 Evidence · ⚠️ Risks · ✅ Recommendations.
Every finding carries an evidence tag:
[Observed]— verified directly, citing the file and line or the command run and its output[Inferred]— a reasoned conclusion from indirect evidence, with the reasoning shown[Unavailable]— could not be assessed from the repository; the access needed is stated
Metrics are measured, never estimated. Where something could not be measured, the report says so and names the data needed. The executive summary consolidates every [Unavailable] item into a list of follow-up questions and access requests for the vendor.
🧪 Method
Measured with cloc, lizard (cyclomatic complexity), jscpd (duplication), Vitest with V8 coverage, Playwright, npm audit, license-checker and gitleaks, alongside a manual review of the code, schema, migrations and documentation. Ratings use a 1–5 scale: 5 Excellent · 4 Good · 3 Adequate · 2 Poor · 1 Critical.
Limits: the source was supplied as a single squashed commit, so history-based analysis (churn hotspots, contributors, delivery metrics) was not possible, and no live deployment, database or hosting account was accessed.