The backend kit
Open-source packages that make the boring decisions once, for developers and for coding agents.
$ ./generate.sh Invoice
src/app/Invoice/IInvoice.ts
src/app/Invoice/Invoice.entity.ts
src/app/Invoice/Invoice.dao.ts
src/app/Invoice/Invoice.service.ts
src/app/Invoice/Invoice.controller.ts
registered in database.ts and setup.ts- 1
- command scaffolds an entity: interface, model, DAO, service, controller
- 2020
- when it started; every new backend we build still starts here
- 0
- migrations an agent is allowed to write
The base classes do the boring part
postgres-backend ships abstract classes for the CRUD layer: BaseEntity, Dao, Service, and ServiceController. Read, list, create, update, and delete are already written, so you only reach for the raw database when a query does not fit.
Run ./generate.sh Invoice and you get an interface, a TypeORM entity, a DAO, a service, and a controller, registered and ready. Every function returns the same Result shape, so nobody guesses whether something throws or returns null.
Logs that know where they came from
Logging goes through smoke-context instead of console.log. It carries request-scoped context through every await without threading an ID through function signatures, and each line names the class and function that wrote it.
Written down for the agents too
The template ships an AGENTS.md and a CLAUDE.md that spell out naming, column types, the Result pattern, and where to stop. Migrations are off-limits: an agent can change an entity and describe the migration it needs, but a person writes it.
Pointing an agent at generate.sh instead of asking it to write five files from scratch means the scaffolding is right by construction. Its job shrinks to the fields and the business logic.
Still moving
This year we added a Valkey service and opened an access-control module, and started folding the pieces into a monorepo. The Next.js frontend template does the same job for client frontends.