I built a cloud architecture tool that generates diagrams, costs, and runbooks from plain English — here's how

abhishek singh — Fri, 05 Jun 2026 01:49:41 +0000

I built a cloud architecture tool that generates diagrams, costs, and
runbooks from plain English — here's how

The problem I kept hitting

Every time I sat down to design a cloud system, I ended up doing this:

Open architecture drawing tool
Add an EC2 node
Think: what's the SLA on EC2 again?
Open a new tab → AWS docs
Think: wait, should this be Fargate instead?
Open another tab
Think: what are the Lambda concurrency limits?
Open another tab
Think: how much is this going to cost at medium scale?
Open another tab

By the time I had answers, I'd lost the thread of what I was designing.
The diagram sat there with 3 boxes and 2 arrows while I was buried in
documentation.

Then I'd share the diagram in a design review. The first question:
"What's the SLA on RDS Multi-AZ?" Back to the tabs.

I got tired of it. So I built Potato.

What Potato is

Live demo →
GitHub →

Potato is a free, open-source Cloud Architecture Studio where every
node already knows the answer to the questions you'd normally open 10
tabs to find.

Hover over any service on the canvas and you get:

What it does — one crisp sentence, no marketing copy
SLA — exact uptime commitment (99.9%? 99.95%? 99.99%? it varies more than you'd think)
Hard limits — Lambda's 15-minute execution cap, DynamoDB's 400KB item limit, API Gateway's 10MB payload maximum
Common production pitfalls — the mistakes that bite teams at scale, not in a hello-world
When to use it (and when not to)
Monthly cost estimates — Small / Medium / Large workload breakdowns, per service, totalled across the whole diagram

52 AWS, Azure, and GCP services documented. 12 production-ready AWS
templates (VPC + ECS Fargate, serverless API, multi-region
active-active, data pipeline, and more) that load in one click.

No account. No login. No subscription ,with
zero network dependencies.

The AI workflow — how it actually works

This is the part people ask about most.

The "AI Import" feature doesn't call any AI API itself. Instead, it
gives you a prompt to paste into whatever LLM you already use — Claude,
ChatGPT, Gemini, anything. The LLM returns a structured JSON block.
You paste that JSON into Potato. Your diagram builds itself.

Getting this prompt to return reliable, parseable JSON across
Claude, ChatGPT, and Gemini took the most iteration of anything in the
project. The key lessons:

1. Schema specificity beats natural language instructions.
The more concrete the JSON schema, the fewer hallucinated fields you
get. If you say "return a JSON object representing the architecture,"
you get something different every time. If you give the exact shape
with typed examples, you get consistent output.

2. "Act as" framing changes the quality of architectural decisions.
Asking an LLM to act as a Principal Solutions Architect (rather than
just "design this system") produces meaningfully better service
selection. It uses RDS Multi-AZ instead of a single instance. It adds
a NAT Gateway. It puts the right things in private subnets.

3. Let the LLM place nodes; don't ask for pixel-perfect layouts.
The JSON includes x / y coordinates. Early versions tried to have
the LLM produce a pretty layout. This never worked reliably. The better
approach: accept any layout from the LLM, then auto-arrange or
manually drag. The architectural structure matters; the pixel positions
don't.

4. Validate after paste, not before.
Rather than trying to validate the JSON mid-prompt, I let the LLM
return what it returns and validate on import. Unknown node types fall
back to a generic icon. Missing fields get defaults. This makes the
feature tolerant of slightly imperfect LLM output without breaking.

The result: describe a system in plain English, get a wired diagram
with 20–40 nodes in about 15 seconds. Then hit Play and the
diagram narrates itself step by step.

What's next

A few things I want to add:

[ ] Terraform / CDK export — generate IaC stubs from the diagram
[ ] More service icons — Kubernetes, Kafka, Snowflake, Databricks
[ ] Diff mode — compare two architecture versions visually
[ ] Team sharing — a lightweight URL-based share that encodes the diagram state

View on GitHub →

If you try it, I'd genuinely like to know what you think — especially
if you're a solutions architect or work in DevOps and have opinions
about what's missing from the knowledge base.

DEV Community: abhishek singh

I built a cloud architecture tool that generates diagrams, costs, and runbooks from plain English — here's how

The problem I kept hitting

What Potato is

The AI workflow — how it actually works

What's next