IaaS task documentation generator for internal teams

The moment it breaks: a mid-sized company has been running on AWS or CloudStack for two years, and the engineer who set everything up has left. The person who inherits the account has to figure out how to do routine tasks — add a disk, change a security group, update DNS — by navigating a console that users describe as 'arcane' and 'a bit difficult to get lost in.' There's no internal runbook, and the vendor's own documentation assumes you already know what product you need.

The reason this keeps happening is that engineers who are fluent in IaaS consoles don't write documentation for non-experts because they don't perceive the interface as hard — it's only hard if you don't already know the mental model. So the documentation gap is invisible until the expert leaves. By then it's too late.

The IaaS vendors themselves have no incentive to fill this gap because their documentation is written to cover every option, not to describe your specific setup. A company running three EC2 instances behind a load balancer with RDS needs documentation scoped to their actual configuration — not the full AWS reference manual. Users complain that 'doing complex stuff is sometimes difficult' and 'configuring DNS and other more advanced features could be easier' — which reflects the absence of guidance specific to their own environment, not a lack of general docs.

This need recurs every time someone new joins the team, every time a vendor requires a configuration change, and every time something breaks at 2am and the person on call doesn't know the console. Companies that don't solve this pay in engineer time, support escalations, and mistakes made by people who were guessing.

What to build

Build a tool that connects to a cloud account via read-only API access, maps the current infrastructure configuration, and generates a set of step-by-step internal runbooks — scoped to that account's actual resources — covering the 20 most common admin tasks, exportable as Confluence pages, Notion docs, or plain markdown.

Where to start

Start with AWS specifically and target engineering managers at companies that have recently had DevOps team turnover — findable via LinkedIn job postings for 'AWS' or 'cloud infrastructure' roles, where the posting itself signals someone just left — and offer the first runbook generation free as a lead-in.

The hard part

The hardest early challenge is that the people who most need this product — teams without strong DevOps — are also least likely to discover it, because they don't know what they're missing until something breaks; distribution into this audience requires reaching them before the crisis, not after.

How it makes money

Per-account subscription billed annually, with pricing tiers based on the number of active resources in the account; one-time setup fee for teams that want a human review pass on generated documentation.