Guided IaaS onboarding for non-technical cloud buyers

The moment it breaks: a small business or startup has just signed up for AWS or Alibaba Cloud — usually because a developer recommended it or a vendor required it — and the person who has to actually set things up isn't a cloud engineer. They open the console and immediately face what users call 'innumerable products with names not indicative of their functions.' They can't find where to add a disk, can't understand the DNS section, and can't tell what they're about to be charged for.

This gap persists because IaaS vendors have zero incentive to simplify onboarding for non-technical users. Their enterprise sales motion targets CTOs and DevOps leads who already know the terminology. The non-technical admin managing the account — the office IT person, the ops manager, the founder — is an afterthought. Nobody internally champions their confusion because they don't show up in sales calls.

Existing IaaS consoles are architected around product teams: EC2 here, RDS there, VPC somewhere else. A user who just wants to 'add a database' has to already know that means RDS, that it lives in a different section, and that it requires a VPC to already exist. That architectural fact — consoles mirror internal org charts, not user goals — is exactly why this is structurally awkward to fix from inside the vendor.

Without a layer between these users and the console, companies either pay for a consultant every time something needs to change, or the developer who set it up becomes a permanent dependency for routine tasks. That costs real money on an ongoing basis — not a one-time setup pain.

What to build

Build a web app that connects to a user's AWS or Alibaba Cloud account via read/write API credentials and presents a task-based interface — 'add a database', 'set up a new server', 'point a domain to this app' — that translates user intent into the correct sequence of API calls across services, showing plain-English confirmations before executing anything.

Where to start

Start specifically with AWS account owners who have been added as billing admins but not as engineers — the person paying the invoice but not the one who set it up — and build the first use case around reading and understanding the current bill and which services are running, before expanding to any write operations.

The hard part

Getting API credentials and permissions scoped correctly for each cloud provider is itself a technical task — which means the exact user you're trying to serve may not be able to complete setup without help, creating a chicken-and-egg problem before they ever see the value.

How it makes money

Monthly subscription per cloud account managed, priced per seat for additional team members who need access — starts free for one account, charges begin at the second account or when write operations are enabled.