DeployWhisper AI
- NLP
- Cloud deployment
- IaC
An infrastructure-as-code orchestrator that translates natural language into scalable cloud deployments on AWS and GCP.
Who it was built for
Built for
DeployWhisper AI
Sells cloud provisioning to teams with no DevOps hire. Describe the infrastructure in a sentence, get Terraform, a pipeline and a running environment.
The brief
The buyer can build their product but not their pipeline, and cloud setup is where their launch date goes. The generated infrastructure had to be something a senior engineer would sign off on, or the whole idea is a toy.
What we delivered
Plain English into Terraform
Logs while it happens
Credentials held properly
Output you can read and edit
Where the growth comes from
Shipping without a DevOps salary
Standard architectures in minutes
Transparency is the adoption lever
The business analysis
DeployWhisper is priced against a hire. That single fact determines everything about how the product had to be built, because a team choosing between a subscription and a DevOps engineer is not comparing convenience — it is comparing accountability. A tool that produces infrastructure nobody senior would approve does not save the salary, it defers it. So the commercially decisive feature in this build is not the natural-language interface. It is that the output is ordinary Terraform, readable and editable, in the customer's own repository.
- Organisations with a cloud security incident in 2024
- 83%
Source · SentinelOne Cloud Security 2025, as reported by DevOps.com
- What comes out the other end
- Terraform
Model · Architectural fact, from the build described in this case study.
- Vault for the most dangerous secrets a company has
- 1
Model · Counted from the delivered scope in this case study.
The buyer is not short of ability, they are short of a specialist
The customer here can build their product and cannot build their pipeline. That is an extremely common shape of company and a difficult one to sell to, because the alternative to the subscription is not a competitor — it is recruitment. A DevOps hire is a fixed annual cost with a long lead time; the product is a monthly cost available this afternoon. The comparison is favourable, and it collapses the moment the buyer suspects the generated infrastructure is not production-grade.
What a team is actually choosing between
Search, notice period and ramp-up before the first environment exists. Highest quality, longest lead time.
The usual outcome. It works, and it costs the roadmap three weeks of the most expensive person on it.
Generation is minutes; the review is the part that takes real time, and should.
Model · Our estimates of elapsed time for a standard VPC, database, queue and CI setup by each route. Illustrative comparison, not measured at any customer.
The risk the product takes on
This is the only project in this portfolio where the software is handed the keys to everything. It asks for cloud IAM credentials and GitHub tokens, and it then creates real resources with them. Research reported by DevOps.com found 83% of organisations experienced at least one cloud security incident in 2024, with misconfiguration behind 23% of cloud breaches 1; IBM puts the average cost of a breach at $4.45m 2. A generated-infrastructure product is implicitly underwriting some part of that exposure, and the Cloud Security Alliance's own survey attributes a third of misconfigurations to flawed or missing internal guidance 3.
Where the product's credibility budget is spent
- Standard Terraform in the customer's repository. Removes the lock-in objection and the black-box objection at once.
- A dedicated vault for IAM keys and tokens. Failure here is not a bug, it is the end of the company.
- Watching a provision run is what makes someone willing to do it a second time.
- Vector-backed retrieval onto strict module schemas, so output is conventional rather than inventive.
Model · Our weighting of the four delivered capabilities by their effect on a buyer's trust decision.
Constraining the model is the engineering problem
Letting a language model write infrastructure freely produces something that provisions successfully and cannot be maintained. The build's answer is retrieval against strict module schemas, so generation is a mapping problem rather than an authoring one: loose English in, conventional Terraform modules out. That choice is what makes the output legible to the engineer who has to own it.
| Output style | Provisions correctly | Reviewable by a stranger | Maintainable in a year |
|---|---|---|---|
| Clicked into a cloud console | Yes | No — there is nothing to read | No, and it cannot be recreated |
| Freely generated IaC | Usually | Only by whoever prompted it | No, because it follows no convention |
| Schema-constrained modules | Yes | Yes — it looks like every other Terraform repo | Yes, and by someone who has never seen the product |
Chat to cloud, with the review step intact
Describe it in a sentence
Architecture proposed
- ↳ Ambiguous requirement → clarified in conversation, not assumed
Read the Terraformdecision
- ↳ Not acceptable → edited in place, still standard IaC
- ↳ Rejected → nothing was provisioned, and nothing was learned the hard way
Provision, with logs streaming
Own the output
The stack, by responsibility
Workspace
- Next.js
- TypeScript
- Tailwind CSS
- Monaco Editor
Orchestration
- Node.js
- Socket.io
Inference
- Python
- Azure OpenAI GPT-4o
- Pinecone
Credential custody
- Dedicated secret vault
Execution
- Terraform
- AWS SDK
- GCP SDK
- GitHub Actions
What we would watch
| Risk | Why it bites | Early indicator |
|---|---|---|
| Credential blast radius | The product holds keys that can create, and therefore destroy, a customer's infrastructure. A single compromise is existential rather than expensive | Customers asking for scoped, short-lived credentials — a request worth pre-empting |
| Generated misconfiguration | Misconfiguration is a leading cause of cloud breaches, and generated infrastructure inherits the failure modes of its templates at scale | The same insecure default appearing across multiple customers' plans |
| Portability cuts both ways | Standard Terraform in the customer's repo is the reason they adopt, and also the reason they can leave after one successful provision | Strong trial conversion with weak month-three retention |
References
- 1.Common IaC security issues and how to fix them (citing SentinelOne Cloud Security 2025) · DevOps.com
- 2.Cost of a Data Breach Report · IBM
- 3.Secure DevOps and Misconfigurations Survey Report · Cloud Security Alliance
Chat to cloud
Describe it
"A Node API, a Postgres database and a staging environment."
Review the plan
The AI proposes an architecture and asks about the parts that matter.
Read the code
Terraform modules generated and opened for editing.
Provision
Resources and GitHub Actions created, logs streaming live.
Own it
The output is normal IaC in your repository, not a lock-in.
Who it is for
Founders and CTOs
Front-end developers
DevOps engineers
Reference
The engineering write-up
Recommended case studies
Want the version of this built for your business?
Fifteen minutes with the people who shipped it. No deck, no account manager.