Launch a public OpenBot landing page

[danielblignaut]

Outcome

Launch a fast, accessible public OpenBot landing page that explains the product, routes users to the right installation path, and links to the documentation, GitHub repository, and releases.

This must be a public product surface, not another route inside the authenticated OpenBot workspace or Electron renderer.

Current state and boundary

• apps/web is the actual OpenBot workspace UI and its / route renders the product application.
• That web build is also part of hosted and desktop OpenBot installations.
• Adding marketing content to that router would couple the official public site to every fork, control-service deployment, and desktop bundle.

Create a separate static site at apps/site (name may be adjusted during implementation) with no dependency on control-plane APIs, provider credentials, local setup state, or Electron.

flowchart LR
  Visitor["Visitor"] --> Site["Static landing site"]
  Site --> Docs["Mintlify docs"]
  Site --> Releases["Desktop and CLI releases"]
  Site --> GitHub["GitHub repository"]
  User["OpenBot user"] --> Workspace["OpenBot workspace / desktop app"]
  Site -. "separate build and origin" .-> Workspace

Loading

Proposed architecture

1. Independent static application

• Add a lightweight static/SSG application under apps/site using repository-pinned TypeScript tooling.
• It may reuse selected brand primitives and assets from packages/ui, but must not import workspace routes, Connect clients, providers, secrets, or desktop code.
• Produce plain static assets that can be hosted independently and cached at the edge.
• Keep landing-page deployment out of the per-fork OpenBot control-service deployment path. Forks should not unexpectedly deploy the upstream marketing site.

2. Content and calls to action

Keep the first version concise and grounded in shipped capabilities:

• one clear statement of what OpenBot is;
• primary action to install/download OpenBot;
• secondary actions for documentation and GitHub;
• a short desktop/CLI/hosted choice explaining who each path is for;
• a simple explanation of agents, their computers/workspaces, and fork-owned configuration;
• security and ownership language that accurately distinguishes local desktop access, sandboxed computers, agent services, and the control plane;
• current screenshots or a short product demonstration only if they can be kept in sync with the product;
• final links to releases, docs, contributing, security, and license.

Avoid unshipped claims, invented testimonials, pricing, badge walls, decorative gradients, and repetitive card grids.

3. Releases and download resolution

• Resolve desktop and CLI download links from published GitHub release metadata at build time, never with a runtime GitHub token in the browser.
• Provide stable release-page fallbacks when platform-specific artifacts are unavailable.
• Detect the visitor platform only to emphasize a relevant option; always expose all supported platforms.
• Coordinate artifact names and channels with Sign, notarize, and productize the macOS Electron app #32 and the release workflow in Establish GitHub CI/CD and a secure release process #31.

4. Design, accessibility, and performance

• Establish a small repository-owned landing-page token layer derived from the existing OpenBot identity.
• Use simple responsive typography, restrained sections, clear whitespace, and real product imagery.
• Meet WCAG 2.2 AA for keyboard use, focus, contrast, motion preferences, and semantic structure.
• Set explicit budgets for JavaScript, images, fonts, and Core Web Vitals; the primary content and links must work without client-side JavaScript.

5. Hosting and routing

• Deploy the static site as its own project/origin with preview deployments for pull requests.
• Select and document a canonical public domain. Route documentation to the companion Mintlify site and product usage to the appropriate install/launch flow.
• Configure canonical URLs, HTTPS, security headers, cache policy, redirects, robots.txt, and sitemap.xml.
• Keep analytics disabled initially, or add a privacy-preserving provider only after its ownership and consent requirements are decided.

6. SEO and machine-readable discovery

• Add per-page title/description, Open Graph and social images, canonical metadata, structured software/project metadata, and a favicon/manifest.
• Link prominently to the documentation site's agent-readable documentation endpoint rather than copying documentation into the landing repository.
• Ensure download and documentation links are crawlable anchors rather than JavaScript-only navigation.

Suggested initial routes

Start with the smallest useful surface:

/
/download
/security

Use the docs site for installation guides, concepts, reference, contributing, and architecture. Add landing routes only when content has a distinct marketing or trust purpose.

Validation

• Focused unit tests for build-time release selection and platform-link fallbacks.
• Playwright smoke tests for primary navigation, all download choices, keyboard use, mobile layout, and JavaScript-disabled rendering.
• Automated link checking and accessibility checks in CI.
• Lighthouse/performance budgets on preview and production builds.
• Production smoke check for domain, redirects, security headers, metadata, docs links, and release artifacts.

Delivery slices

1. Agree the domain, hosting owner, visual direction, and first-version copy outline.
2. Scaffold the independent static application and shared brand primitives.
3. Build /, /download, and /security with real release/docs links.
4. Add preview deployment, CI checks, metadata, redirects, and production smoke tests.
5. Publish to the canonical domain and verify desktop, mobile, crawler, and no-JavaScript paths.

Acceptance criteria

• The landing page builds and deploys independently of apps/web, Electron, and the control service.
• It imports no control-plane client, credential, provider, or setup-state code.
• A visitor can identify OpenBot and reach a valid desktop, CLI, docs, GitHub, or release path in one or two actions.
• Download links resolve from release metadata with safe fallbacks and no browser-side GitHub credential.
• Content makes no claim for a capability that is not shipped and linked.
• The site is responsive, keyboard-accessible, usable without JavaScript, and passes the agreed performance budgets.
• Canonical metadata, social metadata, sitemap, robots policy, redirects, cache policy, and security headers are verified in production.
• Preview deployments and automated browser/link/accessibility checks run for pull requests.

Open decisions

• Canonical landing and documentation domains.
• Static host/provider and whether upstream owns deployment outside normal fork provisioning.
• Whether the first release uses maintained screenshots, a short video, or no product media.
• Analytics owner and privacy policy, if analytics is enabled at all.

Related work

• Audit and refine the web and Electron workspace UI #17 — web and desktop UI styling refinement
• Establish GitHub CI/CD and a secure release process #31 — GitHub CI/CD and release process
• Sign, notarize, and productize the macOS Electron app #32 — desktop CLI packaging and release artifacts
• Restructure docs and publish an OpenBot Mintlify site #35 — restructure docs/ and publish the Mintlify site