How we build in public: the docs site

Most products ship a marketing site first and documentation later, if ever. We did it the other way around: docs.natapulse.com went live with 64 pages covering every public surface of NataPulse — before this blog existed and without a single landing-page superlative. Here is why, and what rules the site follows.

Why documentation first

NataPulse is a research product. Its output — scored events, narratives, multi-agent reports — is only as useful as your understanding of what the scores mean, where the data comes from, and what the product will and will not do. A tagline cannot carry that. A reference can.

Documentation also keeps us honest. Every page describes the product as it actually behaves today, and the site is reviewed against the live product, not against roadmap intentions. If a page and the product disagree, one of them is wrong and gets fixed.

The rules the site follows

Every page states its status. Each documented capability carries an explicit status badge, so you always know whether you are reading about something generally available, gated, or experimental. No page pretends a planned feature already exists.

Research surfaces say what they are. Pages that document research output carry a standing notice: NataPulse produces evidence and analysis, not investment advice. Probabilistic signals are documented as probabilistic — with their limits, not just their strengths.

Real data only. The docs contain no invented counters, prices or uptime figures. Where a number is illustrative, it is labelled as an example. This is not a style preference; the build fails if an unlabelled figure slips into a page.

Nothing internal leaks. A validator runs before every publish and blocks internal score names, private hosts and control-plane links from ever reaching a public page. The boundary between the product’s public behaviour and its internal machinery is enforced by tooling, not memory.

Static, fast, quiet. The docs site is fully static — no application backend, no account, no analytics trackers, fonts served from the site itself. A documentation page has one job: load instantly and answer your question.

The same rules, everywhere public

This blog is built under the same regime. Posts go through the same anti-leak validation before they can build, follow the same real-data-only rule, and land through the same review process as code. The docs site was the template; the blog inherits it.

That is what “build in public” means for us. Not streaming every internal decision — plenty of the machinery stays private, deliberately — but making sure that everything we do publish is accurate, current and verifiable. A public page you cannot trust is worse than no page.

If you have not read the docs yet, start at docs.natapulse.com. If you find a page that disagrees with the product, that is a bug — and now there is a blog where we will own up to fixing it.