Platform Documentation
This site documents the Kurocado Platform — a shared engineering foundation designed to support multiple products, teams, and applications without duplicating infrastructure or re-solving the same problems.
The Platform centralizes architecture, workflows, tooling, and standards that would otherwise be rebuilt independently across projects. It is intentionally modular, composable, and framework-aware.
This documentation focuses on how the platform works, why certain decisions were made, and how its pieces fit together.
What This Is (and What It Is Not)
This documentation is not a marketing site or a tutorial series.
It is a technical reference and architectural record intended for engineers, platform-minded practitioners, and technical reviewers who want to understand:
the system’s structure
its constraints and tradeoffs
how shared tooling is designed and governed
how consistency is enforced without blocking autonomy
For a narrative account of why the platform was built and what outcomes it enabled, see the Platform case study.
Platform Scope
The Platform provides shared foundations across several dimensions:
Architecture System boundaries, domain modeling, package topology, and runtime concerns.
CI/CD Automated workflows for testing, versioning, previews, and releases.
Developer Experience Shared tooling and packages that standardize how applications interact with APIs, configuration, and infrastructure.
Quality & Testing Testing strategy, QA tooling, and shared utilities designed to scale across applications.
Each section of this documentation focuses on one of these concerns in isolation, while still showing how they connect at the system level.
How to Read These Docs
You do not need to read this documentation linearly.
Recommended entry points:
Start with Context if you want to understand the motivation and guiding principles.
Start with Architecture if you want a system-level overview.
Start with CI/CD or Developer Experience if you’re interested in concrete workflows and tooling.
Use Resources for diagrams, repositories, and reference material.
Each section is designed to stand on its own.
Design Principles
The Platform is guided by a small set of principles that recur throughout the documentation:
Leverage over duplication Shared solutions should reduce total system cost, not add abstraction for its own sake.
Explicit boundaries Packages, domains, and responsibilities are defined intentionally to avoid hidden coupling.
Incremental adoption Teams should be able to adopt platform components without full buy-in or rewrites.
Transparency Architecture, workflows, and tradeoffs are documented openly to enable trust and scrutiny.
These principles are referenced throughout the docs rather than restated in every section.
Relationship to the Case Study
This documentation exists alongside — not inside — the Platform case study.
The case study explains the story, decisions, and outcomes.
The documentation explains the system itself.
Where relevant, individual sections may reference the case study for additional context, but content is not duplicated.
Status
The Platform is an evolving system.
Some components are stable and in active use. Others are experimental, transitional, or intentionally incomplete. This documentation reflects the platform as it exists today, including known limitations and future directions.