How we build in the open — and why it matters.
Most of what we know we learned from code someone else published. Open source is how that debt gets paid — we are preparing to publish the parts of our stack that are infrastructure, not client secrets.
We stand on open foundations
Flutter, PostgreSQL, MQTT, OpenTelemetry — our work exists because these were given away. Contribution is rent, not charity, and we pay it with real engineering rather than good intentions.
Generic tooling should not be a trade secret
A design-token pipeline or a code generator is infrastructure. Keeping infrastructure closed does not protect a studio — it just makes everyone rebuild it. The parts of our stack that are not client-specific belong in the open.
Open code is honest code
Code that will be read by strangers is designed differently: fewer clever assumptions, real documentation, tests that explain intent. Publishing forces the standard we claim anyway.
In preparation
We will not link repositories that do not exist yet — here is exactly what is being prepared for release, so the claim can be checked later:
Design Engine
Our generative design system: a structured brief (domain, personality, palette, typography) becomes design tokens and a production-ready Flutter theme — deterministically, not by vibes. The seed of every client design system we ship.
Design token pipeline
One JSON source of truth, generated into Dart themes, CSS custom properties, and Tailwind config. The unglamorous machinery that keeps every Tribar surface visually consistent — with the naming and versioning rules that make it survivable.
The standard we commit to: when a repository opens, it ships with a real README, working examples, an OSI-approved license, and honest issue tracking. No abandoned placeholder repos, no “coming soon” that never comes.
Want to know when it ships?
Tell us and we will write to you the day the first repository opens — before it is announced anywhere else.
Keep me postedPrefer a project instead? Start a conversation.