I've built enough line-of-business apps to know which parts are always the same. Login. Roles and permissions. Tenant filtering. An admin area. An audit log. Every project starts with me copying the same skeleton and then fixing the same bugs I fixed in the last one.
A while back I stopped copying and started packaging. Coworkee is the result — a modular framework for .NET 10 with a Blazor UI, MIT licensed.
What a module looks like
A module is just a class with a [DependsOn] attribute. Reference it and you get its entities, API endpoints, permissions and pages. The plumbing — auth, tenant isolation, audit, realtime, reporting — is already wired in, so you spend your time on the actual feature.
Auth is OpenIddict under the hood: an OIDC server with sign-in, tokens and tenant filtering, without wiring any of it up yourself.
Getting started
dotnet tool install -g Coworkee.Cli
coworkee new Shop
coworkee run
coworkee run boots Postgres, Redis and Mailpit through .NET Aspire, then starts the app. coworkee ui opens Studio, a wizard that walks through the project name, theme, modules and entities and generates the code.
The one number I keep coming back to
A client entity loads 100,000 rows once, then every query after that runs in the browser — 39-56ms per query, against ~216ms hitting the server every time. That's the difference between a UI that feels instant and one where you can feel the round-trip.
What's included
OpenIddict auth, tenant isolation, an audit trail with undo, realtime updates, reporting, and an admin shell. It builds on MudBlazor and MudBlazor.Extensions (which I also maintain), so if you know MudBlazor the components feel familiar.
Site and docs: framework.coworkee.de
Repo: github.com/fgilde/CoworkeeLib
I'd genuinely like to hear what people run into — the rough edges are the useful feedback.
Top comments (0)