Infrastructure should start with what you need — not with which vendor's syntax you happen to know.
Every organization running infrastructure ends up building the same middle layer: a way to check changes against its own rules, a way to approve them, and a way to prove afterwards that both happened. Most build it badly, under time pressure, at companies that do not sell infrastructure tooling. We think that layer should be something you buy.
The bottleneck was never the writing.
Generative tooling made producing an infrastructure change faster and left everything after it exactly as it was. The queue did not disappear; it moved from authoring to reviewing, where it is more expensive and harder to see.
So teams end up in one of two places. Either they hand-roll the approval and evidence layer themselves — repeatedly, imperfectly — or they skip it and rely on the fact that most changes are fine most of the time.
Neither is a good position to be in when someone asks who approved the change that took production down.
What it costs teams
- Weeks of senior engineering time spent reviewing changes that are almost all routine
- Approval that lives in a chat message and cannot be produced a year later
- Infrastructure that quietly stops matching what anyone intended
- A security questionnaire that is genuinely hard to answer honestly
- Platform engineers rebuilding the same governance layer for the third time in their career
Principles, not a feature list.
These are the decisions we made early and will not quietly reverse when they become inconvenient.
Software proposes. People dispose.
Automation is good at preparing a change and bad at deciding whether it should happen. A person authorizes every change, and no configuration removes that.
Rules come before action.
Your limits are applied to what a change would do — not to how convincingly it was requested. A rule that bends to better phrasing was never a rule.
Success is not correctness.
A change that reports success has told you the request was accepted. Whether your infrastructure now matches your intent is a separate question, and we ask it separately.
Nothing holds a permanent key.
Access to your cloud is granted for approved work and expires with it. If a credential ever leaked, the damage should end where the job ended.
The record is written as it happens.
Evidence assembled after someone starts asking questions is not evidence. What happened is recorded at the moment it happens, and it is exportable.
Your infrastructure is yours.
What we produce is standard and inspectable. If you leave, you keep the estate and lose only the workflow. A platform that traps you had to earn its keep some other way.
Early, and saying so.
The temptation at this stage is to describe the roadmap in the present tense. We would rather be the company you did not have to catch out.
Real today
- The whole path — request, review, approval, application, verification and ongoing checks — running against AWS in production
- The services teams actually stand up: databases, compute, storage, networking, delivery, messaging, certificates
- Your rules, approval boundaries and roles, enforced
- A console for the people asking and the people approving, and a command-line tool for those who prefer it
- A complete, exportable record of every request, decision and result
Not yet
- Azure — built, but not selectable until it has been proven against a real subscription
- Google Cloud — a name on the roadmap, with no work behind it yet
- Usage-based pricing — measured today, not billed that way
- Self-serve signup — onboarding is a conversation, deliberately, for now
- Customers we can name — we have none yet, and we are not going to borrow anyone's logo
A successful change is not proof that the infrastructure is correct.
Intentric design principleJudge us on the version that exists.
Tell us what you run. We will tell you plainly whether we can help you today, or whether you should come back later.