Sign in
Phase 3 — Architecture & Engineering

Ecosystem Build Specification

The monorepo blueprint that makes every app feel like one coherent product

2 min read · Document 12 of 30

Generate this document →

What is this document?

The Ecosystem Build Specification defines the repository layout — web, mobile and desktop apps, shared packages, contracts — and the dependency rules between them.

It is what lets a web app, a Flutter app and a Tauri app share types and behave like one product.

Why does it matter?

  • Without it, teams build several apps several different ways.
  • Shared contracts stop types and events drifting between apps.
  • Dependency direction is enforced, not hoped for.

What's inside?

  • Repository layout — Folders for each app and shared package.
  • Dependency rules — Which packages may import which.
  • Shared contracts — Types, API client and events in one place.
Apps depend on shared contracts — never on each other

How CREAH generates it

CREAH builds this document from your Stage 0 answers and interview. Questions that shape it include:

  • Which platforms ship in the first release?
  • Will each space be a separate app?
  • Which code must be shared?

Example excerpt

## The Golden Rule
If you are about to copy a type, schema, or piece of logic
from one app to another — STOP.
It belongs in /shared.
Copying is never the answer. Reference is always the answer.

Related documents

Phase 3

Inter-App Communication Map

The explicit contract that keeps your spaces talking to the right neighbours

Phase 3

Event Catalog

Every event your spaces exchange, typed and contracted before anyone builds a listener

Phase 3

Architecture Constitution

The blueprint that keeps every space from becoming a separate disaster

Ready to generate your Ecosystem Build Specification?

Start building →See pricing