The challenge
AI coding assistants had made a new class of employee productive: people across Euna who could describe, and increasingly build, a small internal web application that solved a real problem in their team. What they could not do was deploy it anywhere defensible. The realistic outcomes were a spreadsheet that never became a tool, an application running on someone's laptop, or a shadow deployment on an unmanaged account outside IT and Security's field of view.
The organization faced the choice most enterprises face at this point: prohibit the activity and lose the value, or permit it and lose control. The engagement premise was that this is a false choice, and that governance can be automated as thoroughly as the code generation itself.
Our approach
BITSUMMIT built a platform in which a business user works inside an approved template kit and two Claude Code skills, while approval, provisioning, deployment and audit execute automatically across Jira, n8n, GitHub Actions, Terraform, AWS and Cloudflare. Critically, no single actor holds end-to-end control, and that separation is what enforces the approval gate and the audit trail.
Five layers, separated by ownership
Each layer of the platform has a different owner, and none of them can complete a deployment alone.
| Layer | Owner | Responsibility |
|---|---|---|
| Claude Skills | Agent, run by app owner | Gather intake, write the spec, file the approval ticket, customize the template, run the compliance and build checks, push code, monitor deployment, verify the live URL. |
| Jira | IT / Service Management | Route by environment, hold the approval gate for production, store the audit fields, trigger provisioning on a status-scoped webhook. |
| n8n | Cloud Operations | Validate identity, create the repository, grant access, dispatch infrastructure, discover the resulting distribution, write results back to the ticket. |
| GitHub Actions | Cloud Operations | Build the frontend and backend, run database migrations, deploy to object storage, CDN and serverless compute. |
| Terraform / AWS | Infrastructure | Provision the per-application stack: serverless database, functions, API gateway, storage, CDN, secrets, IAM, monitoring and cost budgets. |
| Cloudflare Access + AD | IT / Security | Corporate identity in front of every deployed application. Applications read the token; none implement their own authentication. |
Derive the environment, never ask for it
The platform's central design move is that the user is never asked which environment to deploy to. Asking that question invites the wrong answer. Instead the skill derives the environment silently from the intake conversation, using a first-match rule set.
| Rule | Condition in the intake answers | Result |
|---|---|---|
| 1 | Audience includes external users — vendors, partners or customers | Production |
| 2 | Audience includes another team, department, or the whole company | Production |
| 3 | The application requires elevated credentials beyond the owner's own access | Production |
| 4 | The application performs sensitive actions — modifying records, exposing data to others, unattended scheduled jobs | Production |
| 5 | None of the above: the owner or their immediate team, no elevated access, no sensitive actions | Sandbox |
Sandbox applications auto-approve within seconds, so low-risk experimentation stays frictionless. Anything with real organizational reach routes to a human approver who reads a structured description and either approves or declines, and a decline is terminal, non-appealable by the automation, and reversible only by the approver. The user experiences no interrogation about risk tiers; risk classification simply happens, correctly, in the background. Governance that depends on self-declaration fails quietly. Governance derived from the answers people give naturally holds up, because there is no box to tick incorrectly and nothing to route around.
One ticket, and it is the authoritative state
Every application is tracked through a single deployment request ticket whose status is the authoritative state of the system. Nothing proceeds out of order.
| State | What it means |
|---|---|
| Open | The ticket is filed automatically from the intake conversation, with the app name, environment, owner and a full structured description for approvers. |
| Waiting for Approval / In Progress | Sandbox requests transition automatically; production requests wait for a named human approver. No application code is written before this gate clears. |
| Deployment Ready | The deploy skill verifies the code against a compliance checklist, confirms the owner's source-control identity and organization membership, then transitions the ticket, firing the provisioning webhook. |
| In Deployment Workflow | Orchestration validates identity, creates a private repository, grants the owner administrative access, and dispatches infrastructure provisioning, writing granular sub-status back to the ticket at each step. |
| Waiting for User | A soft-fail state. If an organization invitation is unaccepted, the system waits and re-checks on a schedule for 24 hours rather than failing outright. |
| Done | Infrastructure exists, code is deployed, and the health endpoint has been verified live. The ticket becomes the permanent audit record. |
| Failed | Every unrecoverable path converges here with a machine-written failure reason, so the ticket always reaches a terminal state and never hangs silently. |
One module invocation, one complete application stack
A single Terraform module invocation provisions a complete, isolated application stack. Every resource follows a deterministic naming convention, which is what allows the deployment pipeline to operate without reading infrastructure state.
| Compute and data | Delivery and control |
|---|---|
| Serverless PostgreSQL that scales to zero capacity when idle, so a dormant application costs effectively nothing | Private object storage plus CDN distribution, origin-access restricted |
| Application and migration serverless functions, VPC-placed in private subnets | Mutual-TLS enforcement so the CDN and API can only be reached through the corporate edge |
| HTTP API gateway with the default public endpoint disabled entirely | Database reachable only from the application's own function security group |
| Managed secrets for database credentials and runtime configuration | Log groups, error-rate and latency alarms, and a per-application monthly cost budget with owner alerts |
A security posture that does not depend on good behavior
| Control | Implementation |
|---|---|
| No long-lived cloud keys | All pipeline-to-cloud authentication uses short-lived OIDC federation. No access keys are stored in source control or CI configuration. |
| Least-privilege deployment | Each application's deploy role can update its own function code, write to its own storage bucket and invalidate its own CDN — and cannot create or destroy infrastructure. |
| Privilege separation | Secret management uses a separate role from code deployment. The pipeline that accepts arbitrary code cannot read runtime secrets; the workflow that handles secrets cannot deploy code. |
| Edge-only ingress | Mutual TLS on both the CDN and the API means direct-to-origin requests fail at the TLS handshake. There is no bypass path around corporate identity. |
| Trust scoped per repository | Federation trust policies are scoped to the specific application repository, so one application's pipeline cannot assume another's role. |
| Closed technology stack | A fixed, reviewed set of frameworks and libraries. Applications cannot substitute databases, add unvetted dependencies or introduce server-side rendering without a platform-level change. |
Operability, the part most platforms skip
A self-service platform that produces applications nobody can support is a liability with good marketing. Three deliverables addressed this directly.
- Two runbooks were written and handed over — one covering the skills, ticket state machine and provisioning orchestration, one covering the infrastructure pipeline, Terraform module and application deployment workflows, including failure scenarios, validation steps and rollback procedures.
- Every application ships with administrative health routes — recent logs, request and error metrics, deployment history and a read-only schema view — so owners and support staff can diagnose problems without cloud console access.
- Known operational realities are documented rather than discovered, including the expected first-request warm-up when a database has auto-paused, which the platform surfaces to end users as an explicit warming state instead of an unexplained delay.
The outcome
Shadow IT became governed IT. The path of least resistance now runs through the approval gate, corporate identity and the audit trail, because it is genuinely the fastest path available. Approval became a decision rather than a project: reviewers receive a structured description of audience, data sources, elevated access and sensitive actions, and approve or decline in minutes. Engineering came out of the critical path entirely, with infrastructure provisioning, identity, deployment and monitoring requiring no ticket to a platform team and no manual cloud work.
Cost stays attributable and bounded through per-application tagging, budgets and scale-to-zero databases, so the long tail of low-traffic internal tools does not become an unexplained cloud bill. After the first deployment, redeployment is a single push and iteration is an ordinary commit, with the approval record intact and untouched. The transferable lesson is the one underneath all of it: enterprises do not lose control of AI-assisted development because the tooling is dangerous, but because the compliant route is slower than the non-compliant one. Invert that, automate the governance instead of the prohibition, and adoption and control stop being in tension.
