Stop policing
production
Your design tokens and components are data in your product repo. Every change ships as a contrast-checked pull request. Drift isn't caught late. It's structurally impossible.
Private beta. No spam. One email when I open access. Privacy
Tokens
This demo is live. The page reads these tokens, so an edit restyles the site you are looking at. The pale swatch fails contrast: the gate blocks it and the page keeps its last passing value.
Canvas
{
"color": {
"accent": {
"$type": "color",
"$value": {
"colorSpace": "srgb",
"components": [0, 0.298, 0.875],
"hex": "#004cdf"
}
}
},
"radius": {
"base": {
"$type": "dimension",
"$value": { "value": 4, "unit": "px" }
}
}
}Plain DTCG. The value is the only thing your edit changes.
You made the decision in thirty seconds. You'll be enforcing it for a year
A color. A radius. A spacing step. Approved, documented, handed off. Then the real job starts.
The DM asking for the exact hex
It arrives the week after handoff, and every week after that.
The QA pass that catches the wrong gray
Your file was right. Production drifted anyway, one hardcoded value at a time.
The audit that finds a contrast failure
A failure that was never in your file, found after it shipped.
Every tool in your stack exists to manage the gap between design and production. Drift is what a CEO notices in a board demo, and "token fix" is a line a client reads on the invoice.
Kampa removes the gap. There is nothing left to police.
Not another component library In pilot
Tokens were the first level. Components are the next: every project starts with six, each one bound to your tokens and graded by the same gate before anything can ship.
| Variant | rest | hover | active |
|---|---|---|---|
| primary | 6.8:1 | 8.1:1 | 9.6:1 |
| secondary | 6.8:1 | 6.2:1 | 5.6:1 |
| Variant | rest | hover | active |
|---|---|---|---|
| primary | 5.9:1 | 6.8:1 | 7.8:1 |
| secondary | 6.0:1 | 5.6:1 | 5.1:1 |
Live: pick a color in the demo above and every cell re-grades. The swatch you pick carries a light and a dark value, and both have to pass.
Six starters
- Buttonprimary, secondary
- Inputdefault, invalid
- Checkboxunchecked, checked
- Cardone surface
- Badgeinfo, success, warning, error
- Alertinfo, success, warning, error
Repoint any slot to another token, per variant and per state. Rest, hover and active today; more states are next.
Bound, not copied
Every slot is an alias to one of your tokens. Never a raw value, never detached. Change the token and every component that uses it follows.
Every permutation graded
Text on fill, in every variant, state and mode. Not a sample. A component that fails blocks the push.
Plain DTCG in your repo
Two files per component, next to your tokens. You need neither Kampa nor its docs to read one.
What no other tool in your stack does
Your taste, enforced on every agent, every dev, every future edit.
Zero drift, by construction
Your tokens and components live in your product repository. Your design tool stays downstream of them. Your docs read from them. Production reads from them. So do your AI tools: canonical data they run against, not a DESIGN.md they skim and hallucinate around. There is no sync step, so there is nothing to fall out of sync.
A contrast gate that never fails silently
Every color pair and every component permutation is checked at design time, in every mode. A pair that fails blocks the commit, and the gate names the pair, the mode and the ratio that stopped it. Low contrast can still ship when the design calls for it, as an explicit exemption on the record. As a decision, never as an accident.
A real pull request,
not a copy of one
Token sync tools borrow the language of engineering: diffs, releases, approvals, rollbacks. But review happens in their app, under their roles, on their audit trail. In Kampa, a change is a pull request in your repository.
Decide
Edit tokens and components in Kampa, on the values that ship, not a picture of them.
Check
The gate grades every pair and every component permutation before a commit exists.
Ship
Kampa opens a pull request in your repository. Your reviewers, your branch protection, your merge button. The audit trail is your Git history, which outlives every vendor, including Kampa. The repository can belong to a client or another team. They adopt nothing. They review and merge.
kampa wants to merge 1 commit into main
- Kampa contrast check14 of 14 pass · button 12 permutations
- Buildyour CI, unchanged
The model proposes. Kampa disposes
There is a newer promise too: an agent that edits your codebase and opens the pull request for you. It proves designers belong in the repo. But an agent ships whatever it happened to write, and someone still reads every line to be sure. That is why Kampa exists. A change here is not generated code. It is one validated artifact, contrast-checked before the pull request exists. Your engineers review a design decision, not a diff they have to decode.
Tokens today.
The whole front end tomorrow
Every level of the product will live as production code, and every change will ship the way you made it. Tokens are where it starts. Components are in pilot now.
Tokens
Color, type, spacing, radius. Live for pilot teams now.
Components
Six starters, from button to alert. Every slot bound to a token, every permutation graded.
Screens
Whole pages assembled from your own components, as the thing that ships.
Flows
Journeys end to end. From a single token to a full front end.
Stop drawing pictures of your design system
Tokens and components as production data. Changes as pull requests. Contrast checked before anything ships.
Free for solo use at launch. Paid plans for teams. Privacy
Who's building this
I'm Tonda Pospíšil. Twenty years designing fintech and enterprise products, most of it watching approved design decisions degrade on their way to production. Kampa is the tool I needed on every one of those teams. I'm building it solo, with a small group of pilot testers.
Tonda on LinkedIn