The System of Record for Decisions
Arbtr brings the same rigor to engineering strategy that we bring to code. We believe architecture decisions deserve version control, dependency tracking, and automated enforcement—not scattered Notion pages and forgotten Slack threads.
Our Mission
Every engineering team makes hundreds of architectural decisions—which database to use, how to structure APIs, when to refactor. These decisions compound over time, creating what we call "Strategic Debt."
The problem? Most teams track this in wikis that rot, or worse, in the heads of senior engineers who eventually leave. When someone asks "why did we build it this way?"—the answer is often lost forever.
Arbtr exists to make engineering strategy as visible and manageable as code. We're building the "strategic linter" for CTOs and Principal Engineers who need to govern chaos at scale.
Our Vision
We envision a world where every engineering decision is:
- •Captured — with full context, arguments, and evidence
- •Connected — to the decisions that depend on it
- •Enforced — so implementations don't drift from intent
- •Discoverable — by anyone who needs to understand the "why"
Why We Built Arbtr
We've all been there. You join a team and ask "why does this service call that one through a message queue instead of directly?" The answer: "Oh, that was decided before I joined. I think Tom knew why, but he left last year."
Or you're a CTO inheriting a codebase with decades of accumulated decisions—some brilliant, some outdated, most undocumented. Every refactor is archaeological excavation.
We tried everything: ADR files in Git (nobody reads them), Confluence pages (they go stale), Notion databases (they become dumping grounds). None of them captured the relationships between decisions—the fact that choosing Postgres in 2019 affected how you could build multi-tenancy in 2022.
Arbtr was born from a simple belief: decisions are like code—they have dependencies, they can conflict, they need version control, and they should be linted before merge. We're building the tool we wished existed.
Our Principles
These beliefs shape every feature we build and every decision we make about Arbtr.
Documentation Rots. Graphs Survive.
Static wikis die when they're most needed. Living dependency graphs warn you about conflicts before they become crises.
Rigor Over Consensus
Engineering strategy shouldn't be a popularity contest. We prioritize structured decision-making over endless debates.
Lint Strategy, Not Just Syntax
Your CI catches code bugs—we catch strategic drift. Enforce architectural decisions before they merge.
Friction is the Enemy of Record
Nobody wants to fill out forms. AI transforms messy Slack threads and emails into structured decision records.
Institutional Memory is an Asset
The 'why' behind decisions is as important as the code. Capture context that survives engineer turnover.
Decisions are Versioned Objects
Treat decisions like code—they can be deprecated, superseded, forked, and reviewed. Architecture as Code.
Ready to stop the strategic drift?
Join teams who are bringing structure to their engineering decisions. Start free—no credit card required.