Skip to content

[EPIC] Use-case hub + success stories #52

Description

@stubbi

Context

We communicate use cases only as a small list on the homepage today. This epic builds the primary growth surface: a /use-cases hub plus per-job pages named by the job (the Daytona and Replit pattern), backed by runnable examples in the engine repo, plus the first case study and the flagship engineering post. Each page names the job, shows the one-line hook with the latency number embedded in the code, proves isolation, and links a runnable example.

The strategic spine (from the use-case and positioning research)

  • Category narrative everyone now uses: "a computer per agent." The one validated way to explain fast forking is the fork(2) system call applied to a whole computer: subprocess speed with full hypervisor isolation. Lead with it.
  • Closest competitor is Daytona (fork + snapshot + per-agent-computer). Our wedge: microVM by default (Daytona's default is a container; isolation depth ranks Firecracker microVM > gVisor > container), live fork-to-many shipping today (Daytona's parallel-fork API is still partly roadmap), and OSS + self-host + Kubernetes-native (Modal cannot self-host and frames roll-your-own-k8s as a steep ops burden, which is exactly the burden we remove).
  • Honesty rule: competitor latency figures are their published numbers on different hardware; ours stay reproducible from bench/. Never describe a system that does not exist.

Sub-issues

Backed by engine work

Related existing work (do not duplicate)

Metadata

Metadata

Assignees

No one assigned

    Labels

    epicTracking / umbrella issuegtmGo-to-market, launch, contentpositioningMessaging, positioning, narrative

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions