Docs shipped — twelve pages, written against the real source code

Today I'm shipping the full Observare documentation site.

Twelve pages covering every feature that's actually live: uptime monitoring, SSL expiry, TCP/UDP port checks, cron heartbeats, the Stripe webhook logger, plus account management, subscription, and support. There's a proper FAQ and a getting-started walkthrough too. Find it at observare.co.uk/docs.

The thing I want to share here isn't "look, docs!" — it's the methodology.

Every feature page is written against the actual application source. Not from memory, not from marketing copy, not from the rough picture of the product in my head. For each feature I opened the real code in one window and wrote the doc in the other. Every claim about a retention window, a check interval, a rate limit, a flapping threshold, an error category — every number and every behaviour on every page is grounded in what the code actually does.

Most small-SaaS docs don't work this way. They're written from the founder's mental model of the product, which drifts from reality the moment the codebase changes. The result is docs that are 90% right and 10% quietly wrong — and the 10% is exactly where customers lose trust.

Twelve pages. Twenty-nine real screenshots from a live test account. Honest "what isn't here yet" notes on every page for features still to come. A side benefit for me: docs are also a lever on support load — every question a customer can answer from the docs is an hour of my evening back.

Have a look: observare.co.uk/docs

Question for the room: if you've written docs for a small SaaS, are you writing them from the product or from memory? Curious whether the code-first approach is something others do or whether I'm over-engineering it.