Local setup checker for onboarding developers

The idea

Day one at most startups is a senior engineer pair-debugging a new hire’s laptop: wrong Node version, missing env var, Postgres not running, some certificate nobody documented. The README setup section was accurate eight months ago. Devcontainers solve this properly, but only for teams willing to move their entire workflow into containers, and most teams are not.

The wedge is meeting teams where they are: a manifest file in the repo and an npx command that tells you exactly what is wrong with this machine, with a fix hint per failure. Because the manifest lives in the repo and gates the dev script, it stays current the way READMEs never do, and the init command that scaffolds it from package.json and docker-compose removes the adoption excuse.

Who pays

The buyer is a team lead at a 5 to 30 person startup, paying 19 to 49 dollars a month for the team dashboard; each onboarding already costs half a day of a senior salary, so the maths is trivial. The CLI itself is free and open source, which is the distribution: it spreads repo to repo as engineers change jobs, and the dashboard upsell targets the lead who wants to see who is green before standup.

MVP scope

• doctor.yaml manifest for tool versions, env vars, service reachability and required files
• npx repodoctor with grouped pass/fail output, fix-it hints and CI-friendly exit codes
• repodoctor init that scaffolds the manifest from package.json, docker-compose and .env.example
• Team dashboard showing per-developer check status and most-failed checks
• Anonymised reporting only: check names and results, never values
• Skip for v1: auto-fixing failures, Windows-specific package-manager hints, IDE plugins, monorepo per-package manifests

Build RepoDoctor, a Node.js CLI plus a small web dashboard that verifies a developer's local environment against a manifest committed to the repo. Stack: Node.js CLI (TypeScript, runnable via npx repodoctor with zero install), Next.js dashboard, Supabase for auth and data.

Manifest: a doctor.yaml at the repo root declaring checks in four groups. tools: required binaries with semver ranges (node >=20 <21, pnpm ^9, docker, psql), resolved by running each binary with --version and parsing. env: required variable names, each with a hint string and optional regex for format, values never read or transmitted. services: reachability checks like postgres at localhost:5432, redis at 6379, or an HTTP health URL, with connect timeouts. files: paths that must exist, such as .env.local or a certs directory.

CLI flow: npx repodoctor runs every check and prints a grouped pass/fail report with a fix-it hint per failure (the hint comes from the manifest, e.g. run brew install postgresql@16, or copy .env.example). Exit code 1 on any failure so it can gate a dev script. repodoctor init scaffolds doctor.yaml by inspecting package.json engines, docker-compose services and .env.example.

Dashboard: with a DOCTOR_TOKEN env var set, the CLI posts anonymised results (check names and pass/fail only, never values) so a team lead sees who is green across the team and which check fails most.

Pricing: CLI free and open source; dashboard 29 dollars a month per team.