The honest answer is that the UI is not good enough yet. I know that. And I want to explain why, because it is not an accident and it is not laziness — it is a deliberate sequencing decision that I believe was right.

The harder question at the start was whether the system could model and execute real infrastructure work safely. Not demo it. Not simulate it with mocks. Actually execute a change against live infrastructure, verify the result, and roll it back if it failed. A beautiful UI on top of a shallow control plane would be the wrong product. It would be another tool that looks impressive in a sales call and disappoints in production.

The sequence matters. The architecture has to be proven first — the data model, the execution model, the rollback guarantee. Then the execution has to be proven against real integrations: real cloud APIs, real Active Directory, real Vault clusters, real network devices. Then the rollback has to be verified not just as a theoretical capability but as something that actually works when things go sideways. Only after those foundations are solid does a great UX become the right investment. Building the experience first would be building on sand.

This is not an excuse for poor UX, and I am not proud of the rough edges that exist today. They will get fixed. UX matters enormously — it is the difference between a tool that gets used and a tool that sits on a shelf. But a poor UX on top of a correct control plane can be improved. A beautiful UX on top of a broken execution model cannot be saved with better fonts.

The goal is to get both right. We are not there yet on the experience side. We are further along than the outside might suggest on the execution side. That is the honest state of the product.