Done-for-you · Delivered in 24h

Nobody's first day should be spent
chasing env vars and missing config.

The first time someone sets up an unfamiliar repo, they lose hours to undocumented env vars, missing services, and setup steps that live in one person's head. DevDocs scans your actual config and generates the complete setup guide a new engineer needs — so day one isn't a scavenger hunt.

Get a setup guide Send your repo URL. Setup guide delivered within 24 hours.

From a bare repo to a real day one

What your README leaves out, DevDocs writes down.

Same repo, three views: what the docs tell a new hire, what the code actually needs, and the setup guide we hand back. Real scan of novu.

README says

# Get started cp .env.example .env docker compose up

→

Config actually needs

6 services api · worker · ws dashboard · mongodb · redis 88 env vars in .env.example — 5 explained in docs

→

DevDocs delivers

# novu — Setup Guide All 6 services + start order. Required env vars split from optional. Install & run steps. HIGH confidence · file:line evidence

The gaps a new hire hits on day one

Ran it on outline — docker-compose needs postgres + redis, and the setup docs mention neither.

This is exactly what a new engineer trips over: services and env vars the code requires but the README never told them about. File:line evidence for each one, so it's fixed in minutes, not a lost afternoon.

outline-drift.md

> Config scanned: `package.json`, `docker-compose.yml`, `.nvmrc`, `.env.example` > Docs checked: `README.md` > Commit: `3ed1834` · Generated: 2026-06-23 3 conflict(s) found. ## 1. Services [HIGH confidence] ① Source implies `docker-compose.yml` defines 2 services: postgres, redis ② Doc says `README.md:25-29` — no mention of docker-compose or local service startup ③ Why it matters Engineer clones repo, skips `docker compose up`, app fails to connect. Concrete onboarding break — not a cosmetic gap. ④ Proposed patch + # Start required services + docker compose up -d + # Services: postgres, redis ⑤ Reviewer action: Accept patch · Mark intentional · Ignore with reason ## 2. Env Vars [HIGH confidence] ① Source implies `.env.example` defines 86 vars. Local-required: DATABASE_URL, REDIS_URL, PORT, NODE_ENV, URL + 5 more. ② Doc says `README.md:25-29` mentions 2 var(s): DEBUG, LOG_LEVEL ③ Why it matters 10 vars required for local setup are undocumented — silent failures on first run. (17 secrets, 29 optional integrations, 14 deployment-only — collapsed, not needed locally.) ④ Proposed patch — add to Environment Setup section: + DATABASE_URL, REDIS_URL, PORT, NODE_ENV, URL + FILE_STORAGE, FILE_STORAGE_LOCAL_ROOT_DIR (+ 3 more) ⑤ Reviewer action: Accept patch · Mark intentional · Ignore with reason

The problem

New engineer joins. Day one goes to a scavenger hunt, not code.

The README covers the happy path, but the real setup lives in scattered config files and someone's memory. The new hire pieces it together by trial and error — and loses their first day to a problem that shouldn't exist.

⏱

2–3 days lost per hire

Just getting a working local environment before writing a single line of code.

🔑

Env vars that silently break setup

In .env.example but nowhere in the docs. Engineer copies the file, app fails, no idea why.

🧩

Setup lives in someone's head

The one person who knows the missing steps is in a meeting, on leave, or long gone.

🗺

Every unfamiliar repo starts from zero

Inherited a codebase, or evaluating one to adopt? You're reverse-engineering setup from scratch.

How it works

Send your repo URL. Get a setup guide in 24h.

No setup. No access needed. We scan the actual config files and turn them into the guide a new engineer needs.

Purchase & send your repo URL

After checkout, email your public GitHub repo URL. We'll confirm receipt.

We scan the real config

docker-compose, .env.example, package.json scripts, language versions — the sources that actually define how the project runs.

Get the setup guide

Prerequisites, env vars, services, install and run steps — plus the gaps your README never covered. Ready to hand a new hire or drop into your wiki.

The setup guide it generates

Ran it on Medusa — a 200+ package monorepo.

A complete, ready-to-hand-over setup guide — prerequisites, env vars, services, install and run steps — generated straight from the actual codebase. Accurate because it's built from the config, not someone's memory.

medusa-onboarding.md

# medusa — Onboarding Guide ## Prerequisites - Language: JavaScript/Node.js (monorepo) - Node version: 20.x (via .nvmrc) - Docker required ## Environment Setup Copy .env.example to .env and fill in: NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY DATABASE_URL REDIS_URL STRIPE_API_KEY SENDGRID_API_KEY NEXT_PUBLIC_BASE_URL ... 18 more vars detected across 6 packages ## Start Commands npm run dev # @medusajs/dashboard npm run dev # @medusajs/backend npm run dev # create-medusa-app ... 9 more packages ## Services (docker-compose) - postgres - redis

Get a setup guide for your repo

Send your repo URL after purchase. We scan the config, you get the guide within 24 hours.

repo URL → scan config → complete setup guide → ready for day one

Setup Gap Check

$29

Services in docker-compose the README never mentions
Env vars required to run but undocumented
Start commands that don't match the README
File + line references for every gap
Confidence score per finding
The exact list a new hire needs, nothing more

Get gap check — $29 Delivered in 24h · Public repos

Common questions

Will a new hire actually hit these gaps?

If the setup steps aren't all written down, yes. The scan surfaces exactly what the code requires but the docs don't mention — the services, env vars, and steps a new engineer would otherwise discover by trial and error on day one.

Can't I just do this myself?

You can. It takes 1–2 hours per repo: manually cross-referencing docker-compose, .env.example, and package.json scripts against your README and CONTRIBUTING.md. The scan does it in seconds and delivers a structured report with file:line evidence and proposed patches.

What if a finding is wrong?

Every conflict comes with a reviewer action: Accept patch · Mark intentional · Map to deployment-only · Ignore with reason. You decide what's real. The report is evidence, not a mandate.

Do you need access to my repo?

No. The scan works on public GitHub repos — just the URL. For private repos, email first.

What format is the guide?

Markdown. Ready to hand a new hire, drop into your wiki, or paste into a README. No PDF, no dashboard login.

What if our setup docs are already complete?

Then you get a clean guide confirming it — with the trust trail showing exactly what was scanned. Good to know before your next hire, and most repos turn out to have more living in config than in docs.

Who is this for?

Eng leads and platform teams onboarding new engineers, anyone inheriting an unfamiliar codebase, and teams evaluating a repo before they adopt it. Anywhere a first-time setup costs real hours. Not for hobby projects with no onboarding cost.

Setup-risk guides

Evaluating a tool before you adopt it?

First-hour setup-risk breakdowns for popular self-hosted tools — time to first run, where each one breaks, and whether the pain is docs or product. Free to read.

→ Docmost vs Outline vs BookStack: first-hour setup risk notes

Nobody's first day should be spentchasing env vars and missing config.