The Observare documentation site is live. Twelve pages covering every feature that's shipped so far — uptime, SSL, port, and cron heartbeat monitoring, plus the Stripe webhook logger, account management, subscription, and support — along with a proper FAQ and a getting-started walkthrough. Every page is grounded in the actual application source code, not marketing copy or guesses. You can find it at observare.co.uk/docs.
I want to talk about why I did this — because the easy path when you're a solo founder is to ship a "Docs — coming soon" placeholder and get back to the fun work. I know, because that's exactly what my docs page was for months.
Why docs matter more than you think
When a thoughtful developer is evaluating a small tool, the first thing they do after glancing at the landing page is check the docs. Not the pricing, not the features section — the docs.
Because the landing page is always going to look nice. Marketing copy is cheap. What the docs tell you is whether the product is real. Does it have a troubleshooting section? Is there a page explaining the retention period? Can you find out what happens if the thing you care about fails? Can you tell the difference between what's shipped today and what's still planned?
A placeholder docs page reads as "this product isn't finished, come back later". A real docs page reads as "somebody has genuinely thought this through, and they've written it down".
For a one-person side project, the docs are also a direct reduction in support load. Every question a customer can answer from the docs is one less support ticket landing in my inbox. I'm building Observare on evenings and weekends around a day job — every hour I'm not spending answering "how do I add a new alert channel?" is an hour I get to spend shipping the next feature. Good docs pay for themselves in founder time alone.
And docs force you to walk through your own product fresh, as a new customer would. That's a perspective you rarely get once you're deep in building, and it's the perspective that matters most for new signups. A handful of small cleanups to the dashboard preview and the marketing landing page came straight out of that exercise.
The hard way: reading the code first
Here's the part I'm proudest of.
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 backend services and the matching frontend in one window and the blank doc in the other, and wrote the text against what the code actually does. Every claim about a retention window, a status code, a rate limit, an alert subject line prefix, a check interval, an error category, or a flapping threshold is grounded in a specific line of code I could point you at right now.
This is slower than the sit-down-and-write-from-memory approach. But documentation grounded in the real code has a superpower: a customer reading it and setting up a monitor will see exactly what the docs said they would. No gap between promise and delivery, no surprise footnotes, no "oh, that feature doesn't quite work that way" moments when something actually breaks.
That sounds obvious, but most small-SaaS docs don't work this way. They're written from a 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.
I didn't want that. So I did the slow version, page by page, until every claim was something I could defend line by line against the live source tree.
What you actually get
- Twelve pages organised into six sidebar sections: Introduction · Dashboard · Getting started · Monitoring · Tools · Your Account · Help
- Full feature specs for the four monitor types with exact error taxonomies, rate limits, check intervals, confirmation timing, flapping detection rules, retention windows, and account caps — the kind of technical reference you normally have to dig through a changelog to find
- Real screenshots of every major surface of the app, taken from a live account. No mockups, no dashboard fakes
- Honest "what isn't here yet" sections on every page. If a feature is coming soon, it says so in the doc for that feature, not hidden in a roadmap page
- Navigation that works — searchable sidebar, breadcrumb on every page, prev/next pairing, click-to-zoom lightbox on every image, responsive collapse on mobile
- A proper FAQ with thirty-odd entries across getting started, account management, each monitor type, alert delivery, the webhook logger, billing, and support — every answer either links to the full doc page for the topic or answers the question in place
What it actually took
Candidly: a lot. More than I thought going in.
- Twelve feature pages written against the live source, each one cross-checked against the real product behaviour
- Twenty-nine screenshots captured from a live test account, with realistic data seeded specifically for the Stripe webhook screenshots
- Thousands of lines of markdown across the twelve pages plus the FAQ
- Every internal link cross-checked against the real sidebar navigation so nothing points at a dead or renamed page
- A rewrite of the customer dashboard section on the marketing landing page so the mock actually looks like the real dashboard — pulsing green status hero, real KPI names, live activity feed with the real tag design
- A handful of small UI polish passes picked up along the way, as a side effect of walking through every flow as a new customer would
It's significantly more work than a "Docs — coming soon" page. It's probably the single highest-leverage thing I've shipped since the original uptime monitoring MVP: it removes a category of friction between a potential customer and actually trying the product.
Take a look
Start at observare.co.uk/docs. The getting-started section is the gentle entry point; if you're a developer comparing Observare to something else, the four monitoring pages are where the technical detail lives.
If anything in the docs is wrong, unclear, or just missing, I'd genuinely love to hear about it. Use the contact form and point me at the page. Every correction is a direct improvement — the whole point of getting the docs right is to remove the friction between you and actually trying the product.
Observare is in closed beta at £5/month with a 7-day free trial. If the docs make you curious enough to sign up, that's exactly what they're for.