One contract. Every app.

StackBraid is a professional skeleton for building a real product. You choose your stack — backend, database, frontend, mobile — and get working, already-connected codebases with the plumbing a serious project needs already wired. You write business logic. Nothing else.

Early implementation, no release yet. Both backends' Identity feature is implemented and tested — register, log in, refresh, log out, manage users and roles, all proven against contract/conformance, unchanged between the two (see backends/dotnet/README.md and backends/python/README.md for the real runs). Both the Next.js and Angular frontends' web and admin shells are implemented and verified end-to-end against both backends, unchanged, using the same Playwright script (see frontends/nextjs/README.md and frontends/angular/README.md). The Flutter mobile shell's Identity feature — register, sign in, a session surviving an app restart, profile, sign out — is implemented and verified end-to-end against both backends on the macOS desktop run target (not yet on an iOS or Android simulator; see mobile/flutter/README.md). Remaining database providers and every "professional" capability in the table below are still planned. Every capability below is planned unless explicitly marked implemented.

Starting a serious product costs a week of wiring before the first feature: auth, migrations, background jobs, a queue, observability, localization, an admin panel, a mobile client that matches the API. Each of those is solved in isolation. The combination is not, and every team re-solves it.

StackBraid is that combination, maintained once.

Nobody takes two backends. Because every piece implements the same OpenAPI contract, the frontend never knows which backend serves it — so these are five independent pieces, not sixteen combinations to maintain.

Ready = what is the same in every product. Empty = what differs between products.

Auth is identical in every product ever built, so it ships. Invoices are not, so they don't.

A consequence worth stating plainly: StackBraid ships exactly one feature — Identity. No sample business domain for you to delete.

Essential — auth with roles and refresh tokens · user and role management with admin screens · localization including locale-aware backend errors · a standard response and error envelope · validation surfaced in every client · pagination and filtering conventions · migrations and seeding · configuration and secrets · structured logging with correlation IDs · health endpoints · Docker Compose · CI · the agent layer.

Professional — background jobs · RabbitMQ · file storage · Excel import with row-level errors, and export · PDF generation · templated email · audit log · soft delete · rate limiting · Redis caching · API versioning · realtime · push notifications · the full test matrix.

StackBraid ships its own agent configuration, and it is tool-neutral. Procedures live once as plain markdown playbooks; AGENTS.md is read natively by most coding agents, and each tool gets a thin pointer rather than a duplicated copy.

A skeleton's real failure mode is people abandoning its conventions — month three, someone adds an endpoint by hand, skips the contract, hand-writes a client, and it rots from inside. StackBraid has exactly one correct path, which is what a playbook can encode.

Every dependency shipped here is inherited by every user of this skeleton. Full audit, every licence, every verification date: docs/DEPENDENCIES.md. Direct, top-level dependencies of what exists today:

A CI check (scripts/check-dependency-licenses.mjs) fails the build if a dependency changes version or is added without a matching entry in the audit.

• Product specification
• Architecture
• Folder structure
• Roadmap
• Release checklist
• Dependency licence audit

MIT. See LICENSE.