Minas Sarkisyanwebkoth.com

Own product · In production

Frontend factory

A personal frontend kit: the full set of stock shadcn components, an authored library of blocks and template pages on top of it, and a gallery to preview all of it. The kit sits on disk next to the project rather than being installed from a remote registry.

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.

What the business gets

  • A block transfers by copying a file: it drags along neither fixtures nor a foreign theme.
  • Stock components are never edited, so an update from the official registry stays a safe operation rather than turning into conflict resolution.
  • The theme is the parameter and the structure is the product: the same block looks its own way in every application.
  • A new project’s foundation is reproduced by one command instead of being assembled from memory.
  • Two other systems have already taken the theme and the layer model from here: this is a kit already in use, not an ideal for the future.

From source to result

  1. A description of the screen
  2. The nearest reference page
  3. Blocks and stock components
  4. The token check
  5. The screen in the project

A description of a screen is first matched to the nearest of some two hundred reference pages and only then assembled from blocks: that way the screen has a model to follow rather than only an idea of one.

How it works

The layers are kept strictly apart: stock components are never customized, authored blocks take data through props only and never import fixtures, and template pages own their data. Customization is blocks and pages, never an edit to the stock layer.

Token discipline is not a matter of taste but the condition of portability: a block with a raw colour inside stays foreign in someone else’s theme. So the ban is enforced by a separate command over blocks and pages, while the stock layer is exempt.

The primitives here are Base UI, not Radix, and a separate warning says so: examples from training data are almost always Radix. A button rendered as a link without the right flag only complains in a live browser - neither types nor the linter will catch it.

The kit is not installed from a remote registry: it lies on disk nearby, and Claude Code reads the block source and carries it into the project by the recipe - reinstalling the stock components on the receiving side. What is published as an open registry is something else - this site’s theme and components: the showcase behind the link shows them live, while a machine reads them at /r/registry.json.

Who maintains it now

Me. The kit repository is private; what is open is this site’s showcase of the theme and the components - it carries the install command too.

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

Open the case

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 the case

Open source · In production

Starter application template

From the first commit to a production pipeline - one day

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.
Timeline
one day to a production pipeline
In the box
database, auth with roles, tests, CI, two environments

two of the three systems - on the day of the first commit

The same system pays off on one more step

Open the case

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
Open the case
Type
Own product
Status
In production
In the kit
143 blocks, 76 template pages
Maintained by
an engineer
Replaced
building every screen from scratch
Next.js 16React 19TypeScriptTailwind 4shadcn/uiBase UIrechartsTanStack TableESLintPrettier