Platform Thesis
Ship the shell first. Centralize the boring stuff second.
The monorepo should host shared contracts and a real internal product, not become a storage unit for unrelated code. This shell is the front door for that platform.
First-Cut Scope
- Workspace and app catalog
- Tool and template registry
- Observability and ops hub
- Shared platform capability map
What This Is
The map of your repeated platform work.
This is not meant to be another product dashboard full of vanity metrics. It is the front door for the repos, domains, environments, runbooks, and shared systems you keep needing across products.
Things you ship to users or validate as product bets.
Shared code, CLIs, and internal defaults you want to reuse.
Infra control, CI, access, and execution systems that keep the fleet alive.
At A Glance
Start here if you just need the shape of the system.
Quick Actions
Fast jumps into the things you actually touch most
Ways In
Start from intent, not from remembering where things live
Catalog
Grouped by what each thing is for
Tooling
Shared tools worth hosting once instead of rebuilding per app
Environments
Where things actually run and how to get there
Runbooks / Docs
Where to read, understand, and operate each thing
Control Plane
Shared operational systems and entrypoints
Platform
Common platform capabilities this monorepo should own
Workbench
SaaS to yourself, but for internal execution.
The useful version is a thin control plane over reusable runners, jobs, and guided workflows. The likely substrate is `oficina`-style pull agents plus `flare`, `credkit`, and your repo catalog.
Starter Kits
What every new app should inherit by default
Next Steps