Plan
EXOPortfolio control plane
Priorities, dependencies, release gates, and verified delivery share one accountable operating record.
Private beta · open by preference · portable by design
One control plane.
Every property still its own.
EXO is an opinionated, not restrictive operating system for a portfolio of web products. It names each dimension, preferred standard, and provider boundary—while favoring open-source foundations and preserving a clear path out.
EXO / CONTROL
open foundationhuman gateportable outputTHE EXO STACK
Modern by default. Replaceable by design.
A focused set of standards for state, identity, source, runtime, interface, messaging, customer context, and revenue—held behind explicit boundaries instead of welded into the product.
- ConvexApp state
- ClerkIdentity
- EntireSource + execution
- RailwayRuntime
- shadcn/uiInterface
- ResendMessaging
- TwentyCRM
- StripeWeb revenue
- RevenueCatApp revenue
01 / DIMENSIONS
Every dimension named. Every boundary legible.
EXO makes the stack visible: what each system does, which standard we prefer today, and where a provider can be replaced without taking the product with it.
Source
EntirePortable source · captured context
Entire is the primary Git-compatible forge and preserves agent sessions with source history. GitHub remains an optional compatibility mirror.
App state
ConvexReactive control plane
Convex is EXO’s default authority for App registration, environment state, delivery observations, and release orchestration; the legacy backend is frozen for staged migration.
Identity
Clerk + EXO IDOne identity · scoped access
One shared identity receives explicit App and Page scopes instead of a separate account for every property.
Composition + design
Construct + Puck + shadcnOpen component system
Construct owns Page composition, prompt editing, and approved shadcn components through the Structured Liquidity theme.
Media
Construct Convex + file storageConvex-native · evidence-based exceptions
Construct Convex owns Page media metadata, checksums, lifecycle, and references. Large originals use file or object storage only when the workload justifies it.
Runtime
RailwayBounded host
The host, health boundary, and deployed commit remain explicit and observable.
Delivery
Staging → Release Candidate → ProductionExplicit promotion path
Every environment has one purpose, one artifact, and an unmistakable human approval boundary.
Messaging
ResendOptional service
Transactional delivery stays consent-aware, server-side, and separate from product data.
CRM
Twenty + intake adaptersOpen data · replaceable sync
Customer context stays in the CRM while forms and signals synchronize through replaceable, consent-aware adapters.
Revenue
Stripe + RevenueCatOptional services
Commercial infrastructure is normalized and isolated from the portable product core.
Verification
Health + manifests + approvalsOpen contract
A release is healthy, reviewable, and approved—not merely green in a provider dashboard.
02 / HOW WORK SHIPS
Fast to review. Deliberate to release.
Routine work moves automatically into private Staging after validation. People remain unmistakably in control of the candidate and Production decisions.
01
Plan
Agree on the outcome and one accountable owner.
One EXO work item + Entire session02
Build
Make and validate one coherent change.
Short-lived branch from staging03
Review
See the integrated result privately before release.
Automatic Staging + verified evidence04
Approve
Freeze the exact version proposed for customers.
Owner-directed Release Candidate05
Release
Promote the approved version and verify it live.
Owner-approved Production artifactA green check, push, or provider job is evidence—not permission to skip a stage.
03 / TENETS
Tenets with a point of view.
Opinionated, not restrictive
A clear operating model and reusable primitives—then enough room for every property to remain unmistakably itself.
Open by preference
We start with inspectable, open-source foundations. Proprietary services must earn their place and stay behind a replaceable boundary.
Integrated, not locked in
Content, assets, schemas, and delivery records stay exportable. Leaving should be boring, complete, and documented.
Automated, not unsupervised
Machines observe, compare, and prepare. Humans approve consequential production, billing, domain, and data changes.
04 / PORTABILITY
Built to be worth staying for. Designed to be easy to leave.
export.manifestCONTRACT DEFINED
- Structured contentSchema + NDJSON
- Media originalsFiles + checksums
- Design systemTokens + component data
- Routes and formsSEO + redirects + contracts
- Source and deliveryReferences + manifests
- Static fallbackDeployable archive
Build a portfolio of distinct products without building a new operating system.
Private beta · limited operator cohort