Product positioning

The pitch — three audiences

For editors / marketers

StaticOwl turns a conversation into a working static site — live. Edit content. Publish. Never lose work. Roll back anything.

You write content; the system handles structure, layout, builds, and publishing. AI helps with everything from drafting to image generation to rewrites. Mistakes don't matter — every state is reversible.

For platform engineers

A graph-native versioned site compiler that emits pure static artifacts. Host them anywhere — or use our managed atomic-release CDN.

Releases bundle versions of content + templates + types + routes + settings. Output is plain static HTML/CSS/JS, deployable to S3, CloudFront, Netlify, Vercel, GitHub Pages, or your own server. No runtime dependency on us. For customers who want it, we also ship a managed atomic-release tier that adds content-addressed artifacts + manifest-pointer deploys + Lambda@Edge resolver — same compiler underneath, advanced serving on top.

For compliance / regulated industries

Every published state is reproducible. Every deploy is an immutable graph fact. Every change is provable. SOX, GDPR, HIPAA, FDA Part 11 audit-trail requirements answered natively, not bolted on.

Bitemporal append-only graph + cryptographic audit chain + Release-scoped Reviews + atomic rollback. "Show me the site as it was on January 15" is a single query, not a six-month subpoena response.

Three deployment modes (all first-class)

Customers choose how output gets served. The compiler is the same in every case; only the publishing target differs.

Static export (the default — "host anywhere")

Plain static HTML / CSS / JS / assets, written to:

/index.html
/blog/post-1/index.html
/api/articles.json
/rss.xml
/sitemap.xml
/assets/main.css

Compatible with any static host: S3 + CloudFront, Netlify, Vercel, Cloudflare Pages, GitHub Pages, your own nginx. No runtime dependency on StaticOwl. You can take your site and leave at any time.

GitHub mirror (opt-in — "your content in your repo")

Same compiler. The output goes to a GitHub repo the customer owns: HTML at predictable paths, plus a JSON sidecar per page, plus _meta/ global definitions:

/index.html
/blog/post-1/index.html
/_meta/pages/index.json
/_meta/pages/blog/post-1.json
/_meta/types.json          ← content-type definitions
/_meta/theme.json          ← site theme
/_meta/routes.json         ← route map (when present)
/_meta/release.json        ← this deploy's facts (releaseId, deploymentId, when, env)

One commit per deploy. Push-only — we never read the repo back. The customer can:

• Auto-host via GitHub Pages, Cloudflare Pages, Vercel, or Netlify (they watch the repo and deploy on push)
• Fork or clone for offline inspection / audit / migration
• Reconstruct the site from _meta/ sidecars if they leave us

Required env: STATICOWL_GITHUB_TOKEN (PAT with contents: write) + STATICOWL_GITHUB_REPO (owner/name shape) + optional STATICOWL_GITHUB_BRANCH (default main).

This turns "your content isn't locked in" from a marketing claim into a git clone-able artifact.

Managed atomic-release (opt-in upgrade)

Same compiler, different output target: content-addressed artifacts + sharded manifest + Lambda@Edge resolver. Adds:

• Atomic blue/green deploys via single-write pointer flip
• Instant rollback as a new pointer fact (no rebuild, no copy)
• Content-addressed dedup — a 1M-page site change-1-article rebuild is ~5–10 file uploads, not 1M
• Replay any past state at the CDN layer, not just in admin
• Provable audit chain end-to-end, including which artifact bytes were live when

Trade: depends on our CDN runtime. The other modes stay available — you can run them side-by-side.

How to choose

Operators select via the STATICOWL_DEPLOY_TARGET env var: static-paths (default), github, manifest-pointer, or both.

The architectural moat

We're not a CMS that has good versioning. We're a versioned site compiler that happens to have an editorial UI. That's a different category.

Most CMSes (Webflow, Contentful, Sanity, WordPress) are databases with a publish flag. We're a graph + a release system + a manifest router. The four claims competitors can't fake:

1. Site = f(env, time)

Querying the site at any past (environment, time) tuple returns the exact bytes that were live then — content, templates, routes, theme, settings, all coherent. Two seconds. Sanity does this for content only; nobody does it for the whole site.

2. Reproducible publishing

The same Release produces byte-identical artifacts on independent compile runs. Determinism is enforced by the architecture: stable selector ordering, content-addressed outputs, immutable Releases, AI output baked into content versions (not generated at build).

3. Atomic blue/green via pointer flip

Deploy = a single S3 object write (the manifest pointer). Rollback = the same operation backward. No infrastructure duplication. No mixed-state window. Lambda@Edge resolver routes every request through the active manifest.

4. Append-only deploy history

Every Deployment is a graph fact, never a state mutation. Rolling back twice creates two new facts; nothing is overwritten. Combined with the engine's cryptographic audit chain, "who shipped what when and what was reviewed" is a single query — not archaeology.

One source. Every channel.

The promise "Your website is just one compiled artifact" extends naturally: the same compiler that emits HTML can emit social posts, print flyers, QR-coded signs, email bodies, and ad creative — each derived from the same content, rendered through a channel-specific template, versioned and audited as part of the same Release.

Output kinds (channels a Template can target)

web          — HTML page (default — currently shipped)
social_post  — image + caption (IG / Twitter / LinkedIn / story)
flyer        — print PDF (letter / legal / A4 / tabloid)
sign         — print-resolution PNG/PDF for physical signage
qr_code      — QR code (PNG / SVG, points to graph URL or external)
email        — cross-client-safe HTML email body
ad_creative  — display-ad sized image (banner / square / rectangle / tower)
transcript   — plain text or SEO HTML for video/podcast/talk content

The registry is in packages/core/src/output/output-kinds.ts. Each kind declares its file format, default DPI, allowed aspect ratios, and whether it's compliance-tracked. New kinds are added there first; compiler implementations register against the registry.

Why this matters (the killer use case)

"Show me every public-facing asset derived from Product X during the recall window."

Most CMSes punt on this question entirely — content lives in their database, but social posts live in Buffer, ads live in Meta, signs live in someone's local Figma. There's no single source of truth across channels.

Our model: every output artifact is a Versionable in the graph, bundled into a Release, attached to the source content node. The query above is a single Cypher traversal. "What flyer was in circulation in Q2?" is two seconds, full audit chain, end to end.

That's the wedge in regulated industries (pharma recalls, insurance disclosure changes, legal copy updates), in retail (SKU discontinuation across channels), and for any compliance team that's ever had to reconstruct "what did our customers see?" across the marketing surface.

Phase status

• Web — shipping. Every Release today emits a website.
• QR codes — engine support shipped: generateQR() in core, deterministic, scannable, deployable to lifecycle hooks and templates.
• Output-kind registry — shipped: OUTPUT_KIND_REGISTRY in core enumerates every channel with its print/DPI/aspect-ratio metadata.
• Social, flyer, sign, email, ad — Phase 2: per-kind compilers, brand-aware export, admin UI for channel selection.

What we're NOT building

A freeform design canvas. That's Canva's job. We compile structured content into structured outputs through templates the customer authors. "Generate compliant, on-brand marketing artifacts from structured content." — not "design anything."

Pricing fit

Web-only on Solo/Pro. Multi-channel output unlocks at Business. Custom output kinds + brand governance at Enterprise.

Marketing line

"One Release. Every channel."

Same primitive, four uses

The Release/Deployment model isn't just for "deploy now." Once releases are pointer-facts on a manifest, several capabilities fall out as variations on the same mechanic — no new infrastructure required:

• Deploy = one Deployment fact pointing at a Release. The pointer flips.
• Rollback = the same operation backwards. New Deployment fact pointing at an older Release. Atomic.
• A/B testing = a Release whose manifest entries carry multiple weighted variants for a path. The Lambda@Edge / CloudFront Function resolver runs selectVariant() per request — sticky-by-cookie, deterministic, audit-stamped. A/B is just a Release with two pointers.
• Drip publishing = N Releases with staggered validFrom timestamps. The scheduler fires each Deployment when its validFrom arrives. Three patterns supported (even / random / jittered) plus min-spacing constraints. Preview-then-approve: the timestamps are computed deterministically from a seed, so the customer reviews the exact calendar before committing. Drip is N Releases with staggered validFrom.

Implementation-side: computeDripSchedule() in core handles timestamp distribution; selectVariant() in manifest.ts is the pure selection function (deployable to Lambda@Edge or a CloudFront Function unchanged); ManifestEntry.variants[] carries the variant array.

The four killer demos

These are what win deals, in order of impact:

1. "Show me the site as it was on Jan 15." → 2 seconds. Renders the historical site in full fidelity (content + templates + routes + theme + settings).

2. "Roll back the entire site, including theme and routes." → one click. Atomic. No partial state. Audit-stamped.

3. "Show me everyone who approved Release 42 and what they flagged." → single graph query. SOX-relevant.

4. "Prove this exact content was live on a specific date." → cryptographic proof via the engine's audit chain.

Webflow / Contentful / Sanity / Kentico can demo none of these without rebuilding their data layer.

Lineage / framing

For technical buyers who want to place us:

• Vercel + Netlify do manifest-driven static deploys (#3 above). They don't have content versioning underneath.
• Sanity does content time-travel (#1, content only). It doesn't extend to templates / theme / routes / settings.
• Datomic / XTDB do bitemporal graphs. They aren't CMSes.
• WordPress / Drupal have audit logs. They aren't append-only or cryptographically provable.

We're the intersection: bitemporal graph foundation + Release/Deployment model + manifest publish layer + AI-guided editorial UI. Each piece exists separately; the integrated stack is the product.

The category bet

If the wedge works, we're the first credible entrant in a category that doesn't have an established name. Working labels:

• For consumers: "AI-compiled content systems" — describe what you want → get a working site with structure.
• For technical buyers: "Versioned site compilers" — content as code, deploys as releases, rollbacks as facts.
• For regulated industries: "Audit-grade publishing platforms" — provable, reproducible, defensible.

Within 2–3 years, "describe what you want → get a working site with structure" becomes the expected front door. Within 5 years, regulated industries demand provable publishing the way they currently demand provable database-write audit. Whichever tool builds both layers on the same foundation owns both markets.

What we are

• An AI-guided CMS — the front door is a conversation that produces a complete, working site.
• A graph-native content model — tree structure, typed relationships, allowed-children rules, bitemporal versions.
• A lifecycle platform — onSave, beforeRender, onPublish transforms in a sandboxed VM, scoped per type.
• A versioned site compiler — Releases bundle Versionables; content-addressed artifacts; sharded manifests; atomic pointer flips.
• A deploy governance system — Reviews (AI / automated / manual / compliance) gate deploys with dependency-hash freshness and blocking severity.
• A temporal database for sites — Site(env, time) is queryable for any past moment.

What we are NOT

• Not a visual builder. We compile templates; designers edit HTML + CSS (with AI help). Page Builder zones cover composition.
• Not a headless-only API. We ship rendering, publishing, and the manifest router in the product.
• Not a blog engine. Long-form is supported; structure + lineage matter more than newsletter ergonomics.
• Not a graph database product. The graph is an implementation detail of the compiler. We don't sell Cypher access; we sell what the graph enables.
• Not a Vercel competitor. Vercel runs apps; we publish sites with full lineage. Adjacent, not overlapping.

Who we're for

Primary today:

• Technical-adjacent teams publishing structured content with actual shape — docs, handbooks, knowledge bases, catalogues, case studies.
• Indie makers / solo founders who want AI leverage without lock-in to a page builder.
• Publications whose content model can't fit into WordPress without faking it via tags and custom fields.

Primary tomorrow (with regulated industry features layered on):

• Pharma / finance / gov publishing teams that need cryptographic publish provenance.
• Enterprise marketing teams that want named Releases + multi-stage approval + audit-grade rollback.
• Platform engineers building white-label CMS instances for compliance customers.

Who we're NOT for (yet):

• Pure editorial / newsletter teams (Ghost / Substack are better — we aren't optimized for the writing flow).
• Visual-first agencies (Webflow wins until we have a richer visual surface).

Quotable lines

For the marketing site / sales decks:

• "You don't deploy environments. You deploy references."
• "Your website is a function of time."
• "Webflow rebuilds from scratch. We rebuild only what changed."
• "Rollback isn't a feature; it's a query."
• "Edit content. Publish. Never lose work. Roll back anything." (editor-facing)
• "Manifest-driven blue/green via Lambda@Edge resolver. Content-addressed artifacts. Versioned site compiler." (engineer-facing)
• "Every published state reproducible. Every deploy a graph fact. Every change provable." (compliance-facing)