BTD
I kept rebuilding authentication, permissions, tenancy, audit and project conventions before I could touch the part the customer was paying for. BTD is the foundation I wish I had each time.
$ btd doctor ✓ architecture healthy ✓ contracts verified ✓ workbench ready
BTD is my reusable enterprise starting point: .NET backend, Next.js frontend, RBAC, multi-tenancy, CLI tooling and a visual Studio.
The repetition problem
A new business product often spends its first weeks rebuilding the same foundation: authentication, permissions, tenants, CRUD conventions, audit, localization, data access and delivery setup. Copying an old app only copies old assumptions with it.
I turned the foundation into a product
BTD combines an ASP.NET Core backend, Next.js frontend, CLI and Studio. I use it to make the architecture and workflow repeatable, not to generate code for the sake of generating code.
$ btd doctor ✓ architecture healthy ✓ contracts verified ✓ workbench ready
Guardrails over magic
Architecture rules, security rules and workflows live beside the code. The CLI can scaffold and inspect the system; Studio makes parts of that workflow visible. I want a teammate to understand the rules without needing me in the room.
Where it earns its keep
When I start a feature, identity, tenancy, permissions and the basic application shape already exist. That means more of the work can go into the actual business problem.
$ btd doctor ✓ architecture healthy ✓ contracts verified ✓ workbench ready
What I learned building it
A reusable foundation can become its own trap if it tries to predict every future product. I keep pushing BTD toward strong defaults, narrow responsibilities and visible escape hatches.
Back to all work
Work index ↗