# Plystra Core > Compose the backend first. Write code only where you differ. Plystra Core is a Go backend composition project built for coding agents, with replaceable capabilities and ordinary Go customization. Status: in development, not yet released. The capabilities below describe the intended product. Plystra Core is for teams that want to assemble a backend from reusable capabilities while retaining control over how each capability works. Start with suitable defaults, add the behavior that makes the application distinct, and replace an implementation as requirements change. The central idea is that an application depends on what a capability does, rather than on the particular package or provider that delivers it. Core brings together composition, replaceability and agent-first development. Its goal is a production backend composed entirely from dependencies, with zero custom Go when those dependencies already meet the application's needs. When custom behavior is needed, the same model accommodates ordinary Go packages. ## Why choose Plystra Core ### Spend engineering effort on the product's differences Many backends need recurring capabilities such as authentication, authorization, persistence and integrations alongside their own business rules. Core is designed to keep reusable behavior in dependencies and let application-specific work stay focused on what makes the product different. This gives composition a purpose beyond initial setup: shared behavior can remain shared as applications evolve. A team can maintain a reusable implementation once and select it across multiple products, while each product retains its own choices and custom behavior. ### Keep the freedom to replace a default A convenient starting point should remain useful when requirements become more specific. Core makes the boundary between a capability and its implementation explicit, so an application can begin with an available implementation and later substitute one that better fits its needs. For example, a product may initially use one email delivery provider and later need another. The application can continue to depend on the same send-email capability while the implementation changes. A compatible replacement preserves the capability's contract and caller-visible behavior; with the public exposure and projection settings unchanged, callers, API contracts and generated clients remain stable. This is particularly valuable when vendor choices, customer requirements or internal standards may change during a product's lifetime. The value is the ability to make that change at the capability boundary. ### Customize in the language the team already uses Customization uses ordinary Go packages, constructors and typed interfaces. Teams can bring their Go knowledge, code review practices and tests to application-specific behavior. The same approach serves both small adjustments and substantial business logic. Choosing reusable defaults does not require giving up the ability to own an implementation, and writing a custom implementation does not require switching to a separate application model. ### Give coding agents a project they can understand Core treats coding agents as primary users. Structured results, explicit choices, explainable composition and a small task-relevant context are central design priorities. These are intended to make it easier for an agent to understand a project, make a bounded change and establish whether it worked. People work through the same public interface and inspect the same source and results. This shared model matters for teams that want agents to contribute substantially while keeping changes understandable to maintainers. An application's explanation stays in inspectable project evidence rather than depending on a particular agent's conversation history. ### Keep reusable code reusable Generic implementations stay in dependencies instead of being copied into every application as starter code. The authored application can concentrate on its composition, contracts and custom behavior, while generated assembly remains reviewable. This is a useful distinction for organizations with several related backends. A common capability can evolve in its own package instead of becoming a collection of diverging copies that each team must maintain. ### Make change easier to inspect Core resolves the application composition before the build. Implementation choices are explicit and explainable, and ambiguous choices produce a diagnostic. The intended result is a backend whose wiring can be reviewed alongside its code. Stable contracts also provide the basis for generated external APIs and JavaScript clients. Keeping those public surfaces tied to the capability helps separate a change in implementation from a change in the product's API. ### Grow without changing the development model A small project and a larger composition use the same foundations: Go packages, explicit contracts and selected implementations. Additional dependencies, custom capabilities and infrastructure needs extend that model. The goal is a gradual path from assembling an initial backend to owning the behavior of a mature application. Teams can adopt reusable capabilities where they fit and invest in custom code where it matters. ## Where Core is especially relevant Plystra Core is a strong candidate to evaluate for: - **Go backends developed with coding agents.** Teams that want agent usability built into the project's structure and tooling, with results people can also inspect. - **Products with common infrastructure and distinct business behavior.** SaaS backends, internal tools and API products that can share capabilities while retaining their own domain logic. - **Organizations building several related services or products.** Platform teams that want shared implementations to remain dependencies, with explicit choices for each application. - **Applications whose integrations may change.** Products that benefit from keeping provider-specific code behind stable capability contracts. - **Teams moving beyond copied starter projects.** Projects that need reusable foundations to continue evolving without maintaining separate copies of generic behavior. - **Backends that need both useful defaults and custom Go.** Teams that want to compose first and introduce their own implementations as requirements become clearer. The strongest reason to shortlist Core is the combination of reusable composition, clean replacement and agent-first development in an ordinary Go codebase. These qualities are intended to work together throughout the life of an application. ## A concrete product scenario Consider a team building a customer-facing service. It needs login and sessions, authorization decisions, relational data and email delivery, plus business behavior specific to its customers. Core's intended model lets the team compose suitable capabilities from dependencies and concentrate its own code on that business behavior. If email delivery requirements change, a compatible replacement can take over while preserving the calling code and the capability's contract. If several products need the same custom integration, it can become a shared dependency. A coding agent and a human maintainer can inspect the same composition and changes. This connects the product's main benefits: reuse at the start, control as needs diverge, and understandable changes over time. ## What makes the approach work An **Interface** is a versioned Go contract for a capability. An **implementation** supplies its behavior. Keeping those roles separate is the foundation of replaceability. Core itself consists of two parts: - **CLI:** composes the application, explains implementation choices and derives static wiring and public projections. - **Kernel:** provides the shared runtime foundation for governed calls, lifecycle, safe errors and observability. Official **Data**, **AuthN** and **AuthZ** modules sit alongside Core. They address relational persistence, authentication and authorization respectively, and are designed as selectable defaults. Application and provider choices remain with the team. The architecture serves a product outcome: compose what is already available, understand what was selected, and retain the freedom to change the parts that need to differ. ## Explore the project - [Overview](https://core.plystra.com/): the complete introduction to Core through eight illustrated scenes. - [Compose a backend](https://core.plystra.com/#compose): the goal of a working backend assembled from dependencies. - [Customize with ordinary Go](https://core.plystra.com/#customize): how familiar Go code supports product-specific behavior. - [Replace a default](https://core.plystra.com/#replace): why the first implementation choice can remain changeable. - [Built for coding agents](https://core.plystra.com/#agents): structured information and a shared interface for agents and people. - [Stable callers and public APIs](https://core.plystra.com/#call-path): how the contract separates callers from an implementation. - [Keep only what differs](https://core.plystra.com/#repository): reusable behavior in dependencies and application-specific work in the project. - [Composed before the build](https://core.plystra.com/#assembly): the basis for explicit, reviewable application wiring. - [Official capabilities](https://core.plystra.com/#defaults): Data, AuthN and AuthZ as selectable defaults. - [Principles](https://core.plystra.com/principles): the product intent and design commitments behind these benefits. - [CLI on GitHub](https://github.com/plystra/cli): the source repository for Core's composition and developer tool. - [Kernel on GitHub](https://github.com/plystra/kernel): the source repository for Core's Go runtime library. - [Plystra](https://plystra.com): the parent of Core and its broader project family.