DEV Community

Petrutban Technologies
Petrutban Technologies

Posted on

Building a Pre-Release Documentation Hub for an AI Project (Transparency, Status, Official Links)

#ai #security #webdev #opensource

Why I built a documentation-first hub (before the product is public)

Most early-stage AI projects publish hype first and details later. I’m doing the reverse: documentation, status, and verification first.

Petrutban Technologies is an independent studio publishing practical software and AI project documentation with clear public status labels (pre-release / in development / live) and verifiable links to official sources.

The flagship project is QEVARO — an AI assistant currently in active development (pre-release), with a planned public launch window in late 2026 (subject to change). During pre-release, features and availability may evolve as the project matures.

Quick links (official)

What “pre-release” means here (no marketing gloss)

Pre-release is a status label, not a claim.

It means:

  • the core service is not publicly available yet
  • documentation and structure can change
  • public communication is kept traceable through dated updates and authoritative sources

If two sources differ, I treat these as authoritative (in order):

  1. official releases / version notes
  2. dated updates on the official hub
  3. the verified links page for identity confirmation

The core idea: verifiable public signals

I’m building a minimal but strong “source of truth” system:

1) Dated updates (public record)

A lightweight cadence that makes change visible and auditable (what changed, when, where to verify).

2) A status page for public resources

Not for hype — for clarity:

  • what is operational
  • what is not available yet
  • what changed (and when)

3) An official links hub (anti-impersonation)

A single page listing verified channels.
If it’s not listed there, it should be treated as unofficial.

Indexing and discovery (the boring stuff that actually works)

For a new documentation hub, discovery improves dramatically with consistent technical hygiene:

  • robots.txt points to the sitemap
  • sitemap.xml stays clean and updated
  • IndexNow pings when content changes (for supporting engines)
  • clear internal linking (Home → Updates → key pages)

Example robots.txt baseline:

User-agent: *
Allow: /

Sitemap: https://petrutban.com/sitemap.xml
Enter fullscreen mode Exit fullscreen mode

Security posture (simple, practical)

Even for documentation-only sites, security hygiene matters:

  • a dedicated security contact and disclosure process
  • clear policies (Terms/Privacy) and status labels
  • verification signals to reduce impersonation risk

What’s next

Near-term focus:

  • keep documentation consistent across EN/RO pages
  • publish small, real updates as progress happens
  • expand the verified links hub as more official channels become public

If you’re building a pre-release product: do you document early, or only after launch?

Top comments (0)