Note · how requests become shipped software
Catalyst Build Process
Our team and our customers work off the same board: bugs, feature requests, improvements, ideas. It’s all AI-native, and it’s the single source of truth.
Claude Code triages, builds, and reviews every request. Higher-risk requests get a person’s eyes on the plan, the build, or both, at whichever step the risk shows up. Either way, nothing reaches production until a person decides to ship it.
Where the controls actually are
Submit a request
A customer, or someone on our own team, files a bug, a feature request, an improvement, or just an idea on the same customer-facing board. Nothing splits off into a separate internal tracker. If it matches something already reported, they’re told it’s a known issue right there in the conversation, and their report is added as a vote on the existing request.
Secure hand-off
A scheduled job, running inside our production deployment on separate machines from the ones that pick the request up next, reads new and updated requests and sends them, cryptographically signed, to a separate pre-production environment. Delivery is retried automatically until confirmed, so nothing is lost to a temporary outage.
Queued for review
The request lands in a queue inside its own deployment and its own database, a separate environment that mirrors production but holds no production credentials. Receiving the same request twice is handled safely and never creates a duplicate entry.
Assess the request (Claude)
Claude reads the actual code the request would touch, checking for security-sensitive surfaces, required data-model changes, and blast radius. It then sorts the request onto one of two tracks: the fast track, where Claude’s own review carries it all the way to a committed, reviewed change, or the careful track, where a person reviews the plan, the build, or both before it goes further. A copy tweak or a small UI fix is typically fast track; a change touching auth, payments, or a data migration is typically careful track. If the request is too vague to even judge the risk, it waits for a person to scope it. The same assessment also scopes how much security testing the change needs in step 6.
Review the plan (Claude Artifact)
Claude publishes its proposed approach, the risk assessment, and any data-model change as an interactive document, in plain language. On the fast track, Claude checks this against the same criteria from step 4 and moves on. No code exists yet, so nothing here touches production either way. On the careful track, a person reads the same document and approves or declines before a single line of code is written.
Build the change (Claude)
Once the plan clears review, automated or human, Claude writes the code on its own git branch, separate from the main codebase, running type-checks, linting, and the full automated test suite at every step. Security testing is scaled to what the change actually touches, as set back in step 4. Nothing is merged or released yet.
Review the build (Claude Artifact)
Claude publishes a second, separate document: exactly what was built, what it touched, and the test results. On the fast track, Claude reviews its own work independently of the plan review and commits automatically. On the careful track, a person reviews it independently instead; approving is the exact moment the change is committed to version control. Deploying it is always a separate step, either way.
Release & notify
An engineer pushes the reviewed branch to version control and deploys it to production by hand. The original request is marked resolved on our customer-facing feedback board and linked back to our internal knowledge base, so support materials and in-app help stay accurate. If something’s wrong, code rolls back to the previous deploy instantly. Schema changes are the exception: reverting one also means rolling back its migration, so every migration ships with a tested rollback as part of the same change.
Knowledge stays current (in-app Help Center)
Our in-app Help Center is a separate, purpose-built tool, distinct from Otis, the assistant you talk to. It answers product questions from the same knowledge base, lets people report issues, and shows the roadmap. Once more than one person has reported the same issue, it can also say the issue is “known and being looked at,” never that it’s confirmed.
Most requests run unattended from triage through a committed, reviewed change, with one mandatory checkpoint: deciding to deploy it. Higher-risk requests get a person’s eyes on the plan, the build, or both, wherever the risk shows up. Claude never holds production credentials, and every review decision, automated or human, is logged. Before step 7’s review, an independent pass re-runs the tests itself and flags any change outside what was proposed. A fast-tracked change that turns out wrong in production still gets step 8’s instant rollback and audit trail. See the machines behind automated triage and build, and the local safety net every branch clears before merging.