Building around codebase onboarding for small product teams - feedback wanted
Hey IH,
I'm a founder working on an existing product with a small team, and one problem keeps showing up.
Adding another developer does not automatically make the team faster.
Repo setup is not the issue. Writing the first small PR is usually not the issue either.
The harder part is getting someone new to understand enough of the product and codebase to make a real change without pulling the founder, CTO, or senior engineer into every decision.
Things like:
• which screens, APIs, services, core business objects, and modules are tied together
• which product flow a change belongs to before someone starts editing code
• which services or modules usually need senior review before a PR moves forward
• which areas have weak tests or low confidence and need extra care
• what should not be changed right before a release
• which old product or technical decisions only live in someone's head
I'm exploring a product around this gap.
The core idea is to help small product teams carry codebase structure, product-flow context, senior-review concerns, and release-sensitive notes with the work, so adding contributors creates speed instead of more re-explaining and cleanup.
Current stage: validation / early product direction.
I'd love your perspective:
• Have you hit this when adding devs, contractors, or a co-founder to an existing product?
• What are you using today: docs, diagrams, pairing, PR notes, code walkthroughs, Slack, issue boards, or tribal knowledge?
• What would make this painful enough to pay for?
• What would make you skeptical of a tool in this space?
My goal is to understand whether this is a real problem for small product teams, or just something that feels painful because I'm close to it.
This problem has a structural counterpart in extension/SaaS launch work, which is the angle I'm coming from. Substitute "Chrome Web Store reviewer" for "new contributor" and your list reads almost identically: the reviewer also has the codebase, also has the manifest/PR, and the gap is exactly the implicit product/decision context that lives in someone's head — why this permission is here, which scope expansion is intentional vs accidental, what's a structural constraint vs a fixable mistake. Same shape of problem, different audience.
Two patterns from that domain that might transfer:
The thing that actually moves the needle isn't a generated doc — it's a generated doc keyed on the artifact the new contributor is touching. Generic onboarding docs ("here's our architecture") get skipped because they're not about the current PR. The version that gets read is "for the file/module you just opened, here are the 3 implicit decisions and the 1 person who'd care if you broke them." Surface is per-artifact, not per-codebase.
Second: explicit TODO markers in generated docs beat polished prose. Once you start auto-generating context, the generator will impute things it can't actually verify ("this module probably handles X"). Marking those uncertainties inline ("TODO: confirm with @senior whether this assumption still holds") forces the human in the loop to do the one thing only they can do, and stops the doc from quietly becoming wrong as the codebase drifts.
The hardest version of your problem is probably the last bullet — decisions that only live in someone's head. Even the best static analysis can't extract those; you'd need a lightweight capture loop at the moment the senior is making the decision (commit message convention, PR description template, something). Otherwise you're competing with their memory and losing.
What does your current prototype look like — static-analysis-driven, or are you capturing live developer context somehow? That's the design fork I'd be most curious about.
man, 'technical decisions that only live in someone's head' is the real killer here. repo setup or reading standard api docs is never the issue when onboarding a new contractor or dev.the pain always starts when they make a change in a seemingly isolated module, and it unexpectedly breaks a completely different screen because of a weird data-dependency choice someone made two years ago and forgot to document. right now we just rely on messy code walkthroughs and frantic slack pings right before a release.
if a tool can automatically flag a pr when it touches an area with historically weak test coverage or low confidence without me having to manually leave a github review comment every time, i'd seriously consider paying for it. validation is 100% real.
This is a real problem, especially for small teams where the senior context is not documented because everyone is moving too fast.
The painful part is not onboarding itself. It is that every meaningful change requires hidden product judgment: which flows are connected, which modules are fragile, which decisions are historical, and where a new contributor should not touch without review.
That makes this more interesting than documentation. It feels closer to a codebase judgment layer for small teams.
I’d be careful not to frame it too broadly as “developer onboarding,” because that can sound like docs, checklists, or repo setup. The stronger wedge is helping new contributors avoid expensive wrong changes before the PR even starts.
If you build around that, a harder technical brand like Davoq .com would fit better than a soft productivity-style name. The product is about trust, codebase risk, review boundaries, and product-flow context. That needs to feel serious from the first read.