Notes from the control plane.
Original writing about moving from prototypes to systems people can operate.
From prototype to operable project
The decisions that turn a promising build into an owned workflow.
Read →ArticleRequests are not active services
Why intent, review, and runtime state should remain distinct.
Read →ArticleThe first operational review
A practical checklist for the first conversation after setup.
Read →From prototype to operable project
A prototype proves that a direction is possible. An operable project explains who owns it, how it is configured, how it is released, and what happens when it fails.
Start with the boundary
Write down what the project includes and what it depends on. The boundary should name data, credentials, external endpoints, and the people responsible for decisions.
Make the next action explicit
In the Console, a project and a request are useful records of intent. They are not a substitute for review. Use the documentation to distinguish a request from an active service.
Keep evidence close
A release is easier to discuss when source, configuration, health, and rollback evidence travel together. That is the difference between “it worked once” and “another operator can run it.”
Requests are not active services
A request describes what someone wants to evaluate or configure. A service describes a resource record whose connection and runtime state must be verified in the workspace.
Why the distinction matters
Conflating the two creates false confidence: a saved form can look like a deployment even when review, quotation, provider connection, or approval is still pending.
Read state literally
Use the catalog and service views together. A request can be complete as a record while the service remains not connected. The Orders guide describes this boundary.
Communicate the gap
When a capability is not connected, say what is missing and who can resolve it. Do not infer capacity, pricing, or readiness from a label alone.
The first operational review
The first review should be a short, honest conversation about the path from intent to operation.
Ask about ownership
Who approves changes? Who responds to health signals? Who can roll back? If those answers are unclear, the system is not ready for a handoff.
Ask about runtime context
Confirm dependencies, secrets, endpoints, backups, observability, and the expected region. The runtime checklist is a useful agenda.
Leave with evidence
Record the decision, the next action, and the evidence required to promote. A good review reduces ambiguity rather than producing another dashboard.