The specific moment this hurts: a founder or solo engineer realizes their $40/month instance is no longer sufficient, looks at the next tier, and it's $80/month — double — for resources they only need 60% of. This complaint was stated almost exactly by users: 'the pricing and resource level tier doubles every upgrade, forcing an upgrade from $40/month to $80/month when a $60 option would be sufficient.' They don't need a cheaper cloud, they need to understand whether a different configuration — different instance family, reserved vs. on-demand, a different region — could hit their actual performance need at a lower price point.

The reason this gap persists is that cloud providers display their own catalog, not an optimization across it. Their cost calculators let you price a configuration you already know you want — they don't start from 'I need 4GB RAM, 2 vCPUs, and 500GB storage, show me every combination that hits that including reserved pricing' and rank by total monthly cost. The buyer doing this evaluation is often a technical founder or small-team engineer who doesn't have a dedicated FinOps function — they make the upgrade decision in 20 minutes based on whatever the console shows them, which means they reliably overpay.

What's missing isn't a way to see the price list — it's a way to state requirements in workload terms and get back a ranked list of options with the actual monthly cost under different commitment models. The complaint about bulk purchasing requirements for monitoring services points to the same problem: users don't know ahead of time whether a different tier or commitment structure would cost less for their actual usage pattern.

This is a business because every team that grows hits this decision repeatedly — at 6 months, at 18 months, when traffic spikes. Each time they make the wrong call, they overpay until the next review cycle. The need doesn't go away; it recurs at every meaningful scale inflection.

What to build

Build a web tool where a user inputs workload requirements (RAM, CPU, storage, expected egress), selects one or more cloud providers, and receives a ranked table of instance configurations with monthly cost under on-demand, 1-year reserved, and 3-year reserved pricing, pulling live pricing data from each provider's public pricing API.

Where to start

Start specifically with the AWS vs. Akamai comparison for compute-only workloads, where the price gap is most concrete and the user base (developers who left AWS for cheaper alternatives) is already vocal and reachable through developer communities.

The hard part

Getting the first users to trust the pricing data is accurate — cloud provider pricing APIs are inconsistently structured and some prices are only accessible after login or negotiation, so there will always be a category of pricing (enterprise discounts, spot availability) the tool can't cover, which undermines confidence in the output.

How it makes money

Free for basic comparisons up to three providers; $9/month for saved comparisons, alerts when pricing changes on a tracked configuration, and CSV export — the paid tier targets the person who makes this decision repeatedly, not just once.

See the evidence. The complaints behind this idea, the products they came from, and similar ideas in Infrastructure as a Service (IaaS).

More ideas in Infrastructure as a Service (IaaS)