Open source · In production

Starter application template

A starter application template: one command and there is a project with a database, login-and-password auth, roles and permissions, tests, CI and auto-deploy to two environments. It is not an invented ideal: the template was extracted from systems already running in production, and what it packages is not an idea but an order of work - the delivery pipeline is assembled before the domain part.

The pain

Between «the first screen is written» and «people can use this» there are usually weeks of setup, and it is assembled again on every project.

Now

One command scaffolds not an empty skeleton but a configured workspace: stack, database, auth with roles, tests, CI and two environments with automatic production rollback.

Effect across the steps

05 · Faster processes: The production delivery pipeline is ready on the day of the first commit - the order proven on three systems
06 · Freer resources: The order proven on three systems is folded into a single command; in that same month one team launched seven applications

What the business gets

The «and how do we ship this» question is answered before the first page is written.
Every application is released the same way, so one engineer can fix them all instead of one person per project.
A bad production release rolls itself back - on a smoke check, not on a user’s phone call.
The stack rules arrive with the project, so a company specialist works inside boundaries instead of inventing their own.

From source to result

One command
Project with a stack and a database
Auth, roles and permissions
Tests and CI
Dev and production with auto-rollback

Checks stand between the development branch and production: formatting, linting, types, unit tests and a smoke test on login. Production only updates through review, and a bad release rolls itself back.

How it works

It is more than a generator - it is a configured workspace. The stack rules, skills and six everyday commands arrive with the project: /ship (release), /status (environment health), /logs (logs), /reset-dev (sandbox reset), /request-prod (a production request) and /onboarding (bringing a new person in).

The template was extracted from two systems already running in production rather than built as a «reference for the future»: when their approach changes, the template follows.

The two environments are separate on purpose: the sandbox updates from the development branch, production only through review, with a smoke check and automatic rollback.

Who maintains it now

Me. The template follows the systems it was extracted from.

Other cases for this step

Internal system · In production

Management finance loop

A report in half an hour instead of weeks

The pain: Management reporting was assembled by hand over weeks: exports, merging, double-checking.
Now: The report comes together in half an hour, data pulls itself in, and budget variances are visible immediately.

Before → after: weeks → half an hour
Data collection: pulls itself in

The same system pays off across 3 more steps

Internal system · In production

Product portal

An external PLM replaced in days

The pain: Product data lived in someone else’s system: nothing in it could be changed, and any modification meant months of waiting.
Now: An in-house portal replaced the external PLM in a few days of work. The production delivery pipeline was ready on the day of the first commit, so changes reach people the same day.

Timeline
Delivery pipeline: ready on the day of the first commit
Replaced: an external PLM system

The same system pays off across 2 more steps

Open source · In production

Deploy from chat

A release without manual SSH, straight from chat

The pain: Between «the code is ready» and «people are using it» sits manual fiddling: SSH, a server, a web server, a certificate, a DNS record. Every time from scratch and from memory.
Now: The plugin and the MCP server give Claude Code direct access to the cloud: a server, a database, DNS, a certificate and the release itself are done by a command in chat.

A release: a command in chat instead of manual SSH
In the plugin
Infrastructure: server, database, DNS, certificate - by a tool call

GitHub npm

Own product · In production

Frontend factory

A screen is assembled from ready blocks, not drawn from scratch

The pain: Every new screen started from nothing: its own components, colours and spacing. A block that worked did not travel to the next project - it was nailed to its own theme.
Now: A library of authored sections and template pages on top of stock shadcn components. A block transfers as a file: data arrives through props and the colour comes from the receiving app’s theme.

In the kit
Portability
A project’s foundation

webkoth.com/ui-kit

Type: Open source
Status: In production
Timeline: one day to a production pipeline
Maintained by: an engineer
Replaced: a week of setup on every project

Next.js 16React 19TypeScriptTailwind 4shadcn/uiPrismaPostgreSQL 18PlaywrightGitHub ActionsPM2

GitHub