A startup founder or solo developer spins up an RDS instance, picks something that sounds reasonable, and three weeks later sees a bill they didn't expect — because the pricing page shows per-hour rates but hides the storage I/O costs, multi-AZ doubling, and snapshot charges that only show up at the end of the month. By that point they've already built around the configuration.
This gap persists because the cloud providers have no incentive to make cost legible before you commit. Their pricing pages are architecturally optimized for enterprise buyers who have a finance team to model it — not for a two-person startup trying to figure out whether they can afford a production database at all. The buyer in the enterprise case is a procurement team; the user is an engineer who just wants to ship. Nobody is loudly enough in one place to force a fix.
What's missing isn't a generic cloud cost tool — those exist but operate at the billing level, after the fact. What's missing is something that takes your actual workload shape (rows per day, query patterns, backup retention, region, multi-AZ yes/no) before you provision anything and tells you: at your expected scale, here's what this will cost in month one, month six, and month twelve, with a line-by-line breakdown including the hidden charges. And critically, it should tell you when you're over-provisioned — when an M2Large is overkill and a T3.medium would survive your actual load for the next 90 days.
Users specifically complain that 'the free tier isn't sufficient for running a business in a region, requiring users to opt for M2Large or Medium at a minimum' — meaning they're being pushed into a tier they don't fully understand the cost of. The recurring need is real: every new project, every new hire spinning up a dev environment, every staging database represents another moment where someone makes an expensive configuration decision without the information to make it well.
What to build
Build a web-based pre-provisioning calculator that takes workload inputs (expected rows, query volume, backup retention, region, failover requirements) for AWS RDS and Aurora and outputs a month-by-month cost projection broken down by compute, storage, I/O, and data transfer, with a ranked list of alternative instance configurations that would handle the same load at lower cost.
Where to start
Target developers who are actively comparing RDS versus a self-managed Postgres instance on EC2 — they have a concrete decision to make, they're already doing mental math, and a tool that gives them the answer in under two minutes has immediate, obvious value that spreads through engineering Slack channels.
The hard part
Keeping the cost models accurate as AWS silently changes pricing, introduces new instance families, or adjusts I/O pricing — a stale calculator is worse than no calculator because it builds false confidence, and maintaining pricing parity across regions and instance types is a continuous operational burden that kills solo projects.
How it makes money
Free for basic single-configuration estimates; $9/month for saved projects, multi-configuration comparison, and CSV export of cost breakdowns — positioned as cheaper than one hour of the surprise bill it prevents.
See the evidence. The complaints behind this idea, the products they came from, and similar ideas in Relational Databases.
More ideas in Relational Databases