Analyze SaaS Infrastructure Costs Using Automation
To build a SaaS infrastructure cost analysis service, you must move away from static spreadsheets and toward a nightly verification engine that treats vendor pricing as volatile data. Instead of scraping numbers and displaying them, you build a system that compares literal text strings from vendor pages against your database to detect "drift." If a vendor changes a single word or a pricing tier, your system must flag it as unverified rather than attempting to guess the new cost.
This method is for developers or solo practitioners building B2B benchmarking tools or internal cost-optimization dashboards. It is not a tool for general market research, but for high-precision financial modeling where a $0.00 error in an overage rate can destroy a startup's margins.
What are the core components of the engine?
The engine is not a scraper; it is a verification layer. You are building a system that tracks three distinct layers of data for every service in your stack (e.g., Supabase, Clerk, Stripe, AWS):
- The Plan Metadata: The name of the tier and the specific limits (e.g., "10,000 Monthly Active Users").
- The Literal String: The exact text found on the vendor's pricing page (e.g., "$0.05 per additional user"). You store this as a checksum.
- The Overage Logic: The mathematical rule applied when a user exceeds a tier.
You run a job every 24 hours (using a cron job on a platform like GitHub Actions or a dedicated VPS) that fetches the HTML of the pricing pages. The job does not look for "price"; it looks for the Literal String you stored previously. If the string "per additional user" is replaced by "per seat," the system marks that row as Drifted. It refuses to update the price automatically because an automated update is an unauditable change.
How do you handle the "Unknown" problem?
The biggest failure in cost modeling is the "Zero Bug." Most calculators see a missing rate for high-usage tiers and default to $0.00 or a placeholder. In a real SaaS environment, a missing rate usually means the vendor has moved that pricing into a "Contact Sales" tier or a complex Google Cloud/AWS sub-menu.
My rule for implementation is: Unknown is never zero. If your logic reaches a usage threshold (e.g., 50,000 users for Firebase) where the vendor no longer publishes a direct rate, the calculation must return a "Data Withheld" status. A confident wrong figure is more dangerous than no figure at all. If you are building this for a client, they need to know exactly where the visibility ends so they can budget for human intervention.
What are the actual costs and time requirements?
This is a high-maintenance data product. You are not writing code once; you are managing a living database of vendor volatility.
- Development Time: 40–60 hours to build the initial verification engine, the string-matching logic, and the calculator UI.
- Operational Cost: Minimal. Running a headless browser (like Playwright or Puppeteer) once a night for 30–50 sites costs roughly $5–$15/month in compute (using a small DigitalOcean droplet or AWS Lambda).
- Maintenance Cost: This is the hidden killer. You will spend 2–5 hours per week manually verifying "Drifted" rows where the scraper failed to find the expected strings.
Case Study Range: If you sell this as a subscription to B2B SaaS founders for $50/month, you need at least 100 subscribers to justify the manual labor of constant verification. If you are using it internally to optimize your own infrastructure, the ROI is realized when you catch a 20% price hike in your database or auth provider before it hits your billing cycle.
Where did I fail during implementation?
I initially tried to use an LLM to "extract" the price from the HTML. This was a massive mistake. LLMs are probabilistic; they are designed to be "helpful" by providing an answer even when the data is ambiguous. If a vendor changed their pricing from "$10/month" to "$10 per user/month," the LLM would often report "$10" because it "understood" the intent. This led to catastrophic errors in my cost projections.
The fix was to move to Deterministic String Matching. I stopped asking the AI "What is the price?" and started asking the code "Does the string 'per user' still exist on this page?" If the answer was no, the data was dead. Never use generative AI to report hard financial figures; use it only to help categorize the HTML structure before your deterministic logic takes over.
How does this differ from standard comparison sites?
Most comparison sites (like G2 or general SaaS directories) are marketing tools. They are often populated by vendor-provided data or outdated scrapes. This method is an Audit Tool.
- Accuracy: Comparison sites use "Estimated" pricing. This method uses "Verified String" pricing.
- Transparency: Most sites show a total. This method shows the line-by-line arithmetic (Database + Auth + Payment + Hosting) so you can see exactly which service is driving the cost spike.
- Handling Complexity: Most sites fail at "Merchant of Record" comparisons. A real analysis must compare the raw cost of Stripe (plus the labor of filing VAT/Sales Tax) against the higher, all-in fee of a provider like Paddle or Lemon Squeezy.