---
title: "I Built ShipDocs Before Google Built CodeWiki — Here's What I Learned"
description: When Google launched CodeWiki in May 2026, developers started comparing it to ShipDocs. What most don't know is that ShipDocs was already live, already handling private repos, and already encrypted. Here's the story of how we got here — and the hard lessons about building AI documentation tools that Google is about to learn.
date: 2026-05-05
author: Alex Sofroniev
tags: [founder story, startup, AI documentation, CodeWiki, Google, developer tools, ShipDocs]
image: /OG.png
---

Google announced **CodeWiki** on May 5, 2026. Within hours, my inbox and Twitter mentions were full of the same message: **"Google just built ShipDocs."**

They didn't. But the comparison is flattering — and it tells you something important about where the industry is heading.

ShipDocs has been live since April 2026. We launched with private repo support, AES-256 encryption, a codebase chat that cites file paths, and a CLI that uploads your working directory in seconds. CodeWiki launched with public repos only, no chat, no encryption layer, and no CLI. They're not the same product. They don't solve the same problem.

But Google's entry validates something we bet on a year ago: **AI-generated codebase documentation is about to become a standard part of every engineering team's stack.** The only question is which tool wins — and whether the winner understands what developers actually need.

## The origin story: why we started ShipDocs

ShipDocs started with a specific, personal frustration. In late 2024, I picked up an old codebase I hadn't touched in eight months — a Node monorepo I'd built for a client project. I spent three days re-reading source files, rebuilding a mental model of the architecture, and asking myself questions like:

- "Which service handles the webhook retry logic?"
- "Where's the auth middleware registered?"
- "Why are there two queue implementations?"

The README was two paragraphs. The inline comments were sparse. The only person who knew the answers was me — and I'd forgotten half of them.

I did what every developer does: I pasted the directory tree into ChatGPT and asked it to explain the architecture. The response was confident, well-structured, and **wrong**. It invented a service layer that didn't exist. It described a database schema from a previous version of the project. It was good enough to fool someone who didn't know the codebase, and useless to someone who did.

That was the insight: **LLMs excel at generating text, but they fail at generating truth about code.** The missing piece wasn't a better model — it was a structured representation of the codebase that the model could ground its answers in.

## Building the first prototype

The first prototype of ShipDocs was a Python script. You pointed it at a repo, it parsed the file tree, identified component boundaries from `package.json` files and directory structure, and generated a Markdown doc for each component. No AI chat. No web UI. Just `generate_docs.py` that dropped a folder of `.md` files.

It worked well enough that I used it on three client projects. The generated docs weren't perfect — the prose was robotic, the examples were too long — but they were **accurate**. You could hand them to a new engineer and they could find their way around the codebase in an afternoon instead of a week.

The next step was obvious: what if you could ask questions about those docs? Not "explain this repo in general" — **"where do we handle OAuth token refresh?"** — and get a specific, cited answer.

We built the chat layer on top of the generated docs. Instead of feeding the raw source to a language model, we fed the structured documentation — the Overview, the per-component breakdowns, the key files and exports. The model had context about the codebase without drowning in implementation noise. And because every fact in the docs traced back to a specific file, we could make the chat cite its sources.

That was v0.1. It worked on my local machine. It only handled TypeScript repos. It had no auth, no encryption, no web interface. But the core loop was there: **generate docs → ground chat in docs → cite the source.**

## What we learned from early users

We opened ShipDocs to beta users in February 2026. The feedback killed some assumptions and confirmed others.

### Lesson 1: developers don't trust AI with their code

This was the biggest surprise. Every user asked the same question before importing anything: **"Are you training models on my code?"**

Not "how much does it cost?" Not "what model do you use?" The trust question came first, every time. Developers have seen what happened with Copilot training data, Stack Overflow licensing drama, and the general pattern of "free tool ingests your data, then the parent company monetizes it."

We built a no-training policy into the product from day one. We use OpenRouter with explicit zero-retention endpoints. We don't train on user data. We added `ai-train=no` to `robots.txt`. We wrote it into the privacy policy. And we still get asked about it in every sales call.

**Google hasn't published a no-training policy for CodeWiki.** For a product that handles source code, that's a problem. Even for public repos, developers want to know that their open-source code isn't being silently absorbed into a foundation model.

### Lesson 2: public repos are the demo, private repos are the business

Our beta signup form asked: "What kind of repos do you need documentation for?" 87% of respondents checked "private work repos." 12% checked both. Less than 2% checked "public open-source projects only."

This aligns with what every developer knows: your most important codebase is the one you can't share. It's the one with customer data, proprietary algorithms, internal APIs, and payment flows. That's the codebase that actually needs documentation because it's the one that costs money when engineers can't find answers.

CodeWiki doesn't handle private repos. We knew this was a hard requirement from our first beta user. It's why ShipDocs built OAuth integration, encrypted storage, and per-project access controls before we built the showcase feature.

### Lesson 3: one summary isn't enough

Early versions of ShipDocs generated a single document per repo — essentially what CodeWiki does today. Users told us the same thing: "This is great for a high-level overview, but I need to find the specific doc for the auth system."

We rebuilt the generator to produce an **Overview** plus **one Markdown doc per detected component** — backend, frontend, workers, CLI, migrations, webhooks, infrastructure, whatever the repo actually contains. The sidebar navigation mirrors the architecture. You don't scroll through 40 pages to find the queue retry logic. You click "Workers" and read the doc.

This seems obvious in retrospect, but most AI documentation tools still produce one linear document. Google CodeWiki appears to do the same. The difference between "one summary" and "per-component docs" is the difference between a README and a documentation site.

### Lesson 4: citation matters more than fluency

The first version of our chat interface produced beautiful, fluent answers. Users hated it.

"This sounds right, but how do I know it's not making things up?"

We rebuilt the chat to prioritize **citation over fluency**. Every answer includes file paths and line numbers. If the answer references `backend/src/auth/middleware.ts:47`, you can open that file and verify it. If the model doesn't have enough context to answer accurately, it says "I don't see that in the generated documentation" instead of hallucinating.

The result is less impressive-sounding text and more trust. Developers would rather hear "I don't know" than a confident wrong answer.

## Google's arrival validates the market — and changes the stakes

When Google enters a market, two things happen: it gets **legitimized**, and it gets **competitive**.

CodeWiki legitimizes AI-generated codebase documentation as a product category. A year from now, "generate docs from my repo" will be as normal as "deploy to the cloud." Developers won't explain why they need it — they'll explain why they chose one tool over another.

But Google's launch also sets the baseline. CodeWiki is the reference point now. And because CodeWiki launched with public repos only, no chat, no encryption, and no CLI, it creates an opening for tools that solve the harder problems:

- **Private repos** with secure OAuth and encrypted storage
- **Interactive chat** that cites file paths and refuses to hallucinate
- **Per-component docs** instead of one summary
- **Editable output** that your team can own and improve
- **CLI integration** that fits into your existing workflow

ShipDocs already does all of these. We've been live for a month. We've indexed hundreds of repos. We've learned what developers actually need — and more importantly, what they won't tolerate.

## What Google will learn next

Google has the resources to build every feature ShipDocs has. But resources don't compress time. There are things you only learn by shipping, breaking things, and talking to users.

Here's what I think Google's team will discover in the next 6–12 months:

### 1. The no-training policy isn't optional

Developers will ask about training data constantly. Google's legal and PR teams will need a clear, published answer. "We don't comment" isn't enough when the product ingests source code. ShipDocs learned this on day one.

### 2. Private repos require a complete trust stack

OAuth. Encryption. Audit logging. Compliance documentation. Data residency. The feature set for private repo support is 5x larger than the public repo feature set. ShipDocs spent months on this before we could claim it worked.

### 3. One summary doesn't scale

As soon as CodeWiki indexes a real corporate monorepo, users will ask for per-component navigation. Generating one document for a 500k-line codebase is technically impressive but practically useless. You need architecture-aware boundaries.

### 4. Chat is the killer feature

Reading generated docs is better than reading raw source, but it's still reading. The value proposition of AI codebase documentation is **"ask questions, get cited answers."** Without chat, CodeWiki is a documentation viewer. With chat, it's a productivity tool.

### 5. The CLI matters more than the dashboard

Developers live in the terminal. If the workflow is "open browser, paste URL, wait, read docs," adoption will be limited. If the workflow is `shipdocs upload` from your cwd, you use it every day. ShipDocs' CLI (built with Ink, a React-based TUI library) has higher daily-active usage than the web dashboard.

## Where ShipDocs goes from here

Google's entry doesn't change our roadmap. It validates it. We've been building the documentation platform we wish existed — and now the market agrees it should exist.

The v2 roadmap is already public:

- **Team seats and permissions** for org accounts
- **Public docs portal with templates** — publish your ShipDocs runs as branded documentation sites
- **Versioned docs** tied to git refs so you can browse docs for any tag or branch
- **Scheduled and webhook-based auto-regeneration** so docs stay current without manual updates
- **Multi-language docs** via DeepL so teams can generate documentation in Spanish, German, Japanese, and more from the same source

Beyond v2: visual dependency diagrams, Slack and Microsoft Teams integration, SSO/SAML for enterprise, and deeper IDE integration.

We're also expanding the free tools — the README generator, complexity scorer, Dockerfile generator, production audit, and explain-in-a-tweet — because they're the easiest way to experience ShipDocs without an account. CodeWiki doesn't have an equivalent. That gap is an opportunity.

## The honest take

Google CodeWiki is a good product for its intended use case. It's fast, clean, and free. If you're browsing an unfamiliar open-source library, it gives you a useful overview without requiring an account.

But it's not the product developers actually need. The real problem — the one that costs engineering teams hours every week — is **private codebase documentation**. And solving that requires more than an AI model and a nice UI. It requires trust infrastructure, encryption, a no-training policy, per-component architecture detection, file-citing chat, and a workflow that fits into how developers already work.

ShipDocs built all of that before Google launched CodeWiki. We built it because we needed it ourselves. And we're still building it because the problems — context, trust, accuracy, and workflow — are deeper than one launch can solve.

**Try ShipDocs on your private repo:** [shipdocs.sh](https://shipdocs.sh) — free tier, no credit card. [Get started →](https://shipdocs.sh/#hero)