INPUT DEBT: No tests on the payment flow. jQuery still used on 3 admin pages. Database has 2 tables nobody knows if they are used. Deploys are manual over SSH, take 40 minutes. Node 16 (EOL). One 4000-line controller file. No staging environment. PRODUCT: Booking system for driving schools, 60 paying schools, used daily by instructors and office staff TEAM: Me plus one junior developer, maybe 1 day a week for maintenance work ROADMAP: Online payments with a new provider, promised to customers for November OUTPUT (Claude Sonnet, unedited) ## The verdict The real fire is zero tests on the payment flow while you're about to bolt a new provider onto it, with a junior dev and one day a week of slack. Next two weeks: get minimal test coverage on today's payment flow, and a safe place to try the new provider without touching live billing. ## Ranked | # | Item | Costs you today | Risk if ignored 6 months | Effort | Status | |---|---|---|---|---|---| | 1 | No tests on payment flow | Nothing visible, but no safety net for changes | New-provider work ships bugs straight into billing for all 60 schools, no way to catch regressions | 2–3 days | Do now | | 2 | No staging environment | Every change tested in prod or not at all | New provider gets tested live; risk of double-charging or failed charges for real customers | 3–5 days (minimal version) | Do now | | 3 | Manual SSH deploys, 40 min | Slow, error-prone releases, no easy rollback | Payment rollout needs frequent small deploys; each one is slow, and reverting a bad one is scary | 1–2 days (basic script) | Do next | | 4 | 2 unknown DB tables | Mental overhead, uncertainty | Could be hit accidentally during payment-related schema work; wasted investigation later | A few hours | Do next | | 5 | Node 16 (EOL) | No security patches | (inferred) some payment SDKs drop EOL-runtime support, could force a rushed upgrade mid-integration | 3–5 days incl. testing | Do next | | 6 | 4000-line controller | Slower to read/change, merge risk | Only a roadmap blocker if it contains payment code — not stated either way | Weeks (if refactored) | Carry | | 7 | jQuery on 3 admin pages | None functionally | Isolated, low customer-facing risk | Days (if replaced) | Carry | ## The one to do first No tests on payment flow. Smallest fix: write a handful of integration tests for today's flow only — a successful charge, a failed charge, and the webhook handler — using whatever test setup exists, or a bare script hitting those paths against a sandbox account. Put it in `tests/payments/` and require it to pass before deploying that code. You'll know it worked when the tests catch a deliberately broken change, and the new-provider work runs against them instead of manual click-testing. ## Blocking the roadmap No tests on payment flow: every new-provider change needs manual verification instead of an automated check, adding real days to the November work. No staging environment: the new provider's sandbox/webhook testing needs somewhere that isn't production; without it you'll test live or improvise locally. Manual SSH deploys: payment rollouts need several small, fast deploys with quick rollback; 40-minute manual deploys make each iteration expensive. Node 16 (inferred): if the new provider's SDK needs a newer Node version, you'd hit this mid-integration, forcing an unplanned upgrade under deadline pressure. ## Carry these jQuery on 3 admin pages: fine indefinitely unless those pages need new features or a jQuery security advisory appears. 4000-line controller: fine unless it's the file you must touch for payments — then its size becomes a blocker, not just ugliness. ## What is missing from your list Backups and restore — not mentioned; an untested restore process is a real gap for a system handling bookings and (soon) payments. Observability — no error tracking mentioned, which matters more once a new provider goes live. Single points of knowledge — a two-person team with no documented deploy or payment process is a bus-factor risk your list doesn't cover. ## The two-week plan Week 1: you personally write the payment-flow smoke tests, as part of the payment project itself since it gates safe integration work; the junior spends their one day auditing the two unknown DB tables (check queries/logs, document findings). Week 2: junior spends their day standing up the smallest workable staging setup or a documented sandbox-testing process; you continue payment integration using the new tests as a guardrail. Explicitly postponed: jQuery, the Node 16 upgrade (unless the SDK check forces it), the controller refactor, and deploy automation — revisit after November.