Roadmap

This roadmap is constraint-driven. It lists what we plan to add without breaking the public profile contract:

  • static HTML + CSS
  • no JS on public profiles
  • no third-party resources on public profiles
  • auditable behavior

The dashboard can evolve faster; the public surface is intentionally conservative.

Near-term (launch hardening)

1) Contract tests in CI

Automate the invariants that define the product:

  • 0 <script> tags on public pages
  • same-origin resources only
  • CSS budget (≤ 2 linked CSS files)
  • byte ceilings (compressed transfer thresholds)
  • cache headers on fingerprinted CSS

2) Theme catalog scaling

  • More themes, kept small by design (base + theme CSS split)
  • Theme options remain sparse (themeOptions only stores enabled flags)
  • Premium theme gating (preview for all, save for Lifetime)

3) Custom domain hardening

  • Domain verification (DNS or HTTP challenge)
  • Conflict detection and ownership protections
  • Better status/debugging in the dashboard

Medium-term

1) Static export

Goal: export a profile into a portable artifact that can be self-hosted.

Expected form:

  • single HTML file (with inline CSS in export mode)
  • optional bundled avatar
  • links preserved (direct URLs, analytics optional/off for export)

This should preserve:

  • no-JS public page constraint
  • auditability

2) Click analytics (minimal)

Keep analytics intentionally narrow:

  • server-side redirect events only
  • coarse aggregation
  • clear retention policy

No third-party trackers, no client scripts.

3) Better verification tooling

  • "Verify" page commands integrated into dashboard (copy/paste)
  • optional byte and contract summaries for power users

Long-term / explorations

1) Identity themes (premium)

More "identity signaling" themes that remain professional and restrained.

Guiding rule:

  • themes express identity without becoming cosplay by default
  • playful variants live behind toggles

2) Profile blocks (carefully scoped)

If profile content expands beyond a link list, it must still respect the contract.

Possible examples (still static):

  • short "projects" section
  • pinned link groups
  • small metadata badges (text-only)

No dynamic embeds or JS-driven widgets on public pages.

Explicit non-goals

These are not planned for public profiles:

  • client-side apps or hydration
  • third-party embeds/widgets that require JS
  • tracking pixels, retargeting, ad-tech
  • experiments/A-B tests on public pages
  • personalization based on viewer identity

If a feature requires breaking the public contract, it belongs outside the public surface.

Known tradeoffs

  • The public surface evolves slowly. That's the point: constraints are the product.
  • Some "obvious" features won't ship. If it needs JS or third-party scripts, it's not a public-profile feature.
  • Power users will ask for complexity. The roadmap prioritizes keeping the product coherent over expanding scope.

Contract tests (roadmap-level)

As features are added, these invariants remain non-negotiable for public pages:

  • no JS
  • no third-party resources
  • cacheable, fingerprinted CSS
  • auditable behavior via curl