Skip to content
Alper Sarper
Currently building

Ingot

Capture UI components from any site, merge them into one consistent set of design tokens, and export a design-kit.md an LLM can build against.

Company
Side project
Timeline
2026–Now
Role
Solo developer
Ownership
Core engine · panel server · workbench UI · capture extension · CLI
  • TypeScript
  • React
  • Vite
  • Tailwind
  • Node.js
  • SQLite
  • Chrome MV3

Problem

Context and what success required.

One-click extractors that copy a single site's styles already exist. The hard part is taking components captured from several places and resolving them into one design system that actually holds together — with every decision traceable and overridable.

Who it's for
Indie developers shipping UI with LLMs.
Why it mattered
Styles captured from different sites are not yet a design system, and not something an LLM can build consistent UI against.
Success measured by
Would I ship a real page built against only the exported design-kit.md?

Responsibilities

What I owned on this project.

  • Core engine
    The pure, deterministic core that turns captured components into tokens, a design-kit.md and docs.
  • Workbench
    The panel server and the React/Vite/Tailwind UI for reviewing, overriding and exporting a kit.
  • Capture extension
    An MV3 Chrome extension: pick a component on any page and it lands in the library with a screenshot.
  • CLI
    The ingot-workbench launcher that starts the panel locally with one command.

Engineering

How it's built.

Deterministic engine
No DOM, I/O or network: the same input always produces byte-identical output.
Traceable decisions
Every token carries its provenance, and every close call can be reviewed and overridden.
Assistant guardrails
The optional LLM assistant proposes names and fills gaps, but can never write a token.
Local-first
Designed to run with one command; the library is a SQLite file in ~/.ingot.

Decision Log

The decisions behind the system.

D-01

The LLM assistant never writes tokens

Context

An assistant can usefully propose names, fill gaps and spot duplicates, but colour maths, contrast and scales have to stay deterministic and reviewable.

Alternatives
Let the model write token values directly
Why this
The engine's deterministic core is never the LLM's job; the LLM does the parts that are language.
Trade-offs
Every suggestion goes through review instead of applying instantly.
Outcome
Proposals arrive as review cards and become values only through overrides, with their own provenance.
D-02

A pure engine with no DOM, I/O or network

Context

The same engine code has to run in the extension, in the panel and in CI.

Alternatives
Engine logic inside the server or the UI
Why this
Portability and a hard determinism guarantee.
Trade-offs
All storage, network and browser work is pushed out to the apps around the engine.
Outcome
A purity test reads the engine's own source to enforce it.
D-03

A one-command quickstart first, Docker as the durable path

Context

A first run that needs Docker loses people before they have seen a kit.

Alternatives
Docker as the front door
Why this
A no-account one-liner is the shortest way to a first kit.
Trade-offs
Two launchers to keep in step.
Outcome
One server, two launchers: the CLI starts the same server the container runs. Not yet published to npm.

Notes

Ingot is a work in progress. It handles four component types today (button, card, input and typography); more come next.