Recently, I shared a story about how we ended up building our own LLM Cost Tracker.
It started with a simple question about our AI spending and turned into a product. One of those things that happens when you try to solve your own problem and accidentally discover that other people have it too.
But that's not the only time this has happened at Binadox.
Our product manager has a theory about business ideas. If you want to come up with one, you need to find a problem people have — or, as he puts it, create a problem for them — and then offer a solution.
The first part sounds obvious. The second one sounds a little suspicious. Let's stick with finding real problems.
The funny thing is, he's right.
Every tool we've built started with the same process. First, our product manager looks for problems people are struggling with. Then we try to understand those problems ourselves and figure out how to solve them in a way that actually makes people's lives easier.
There's research, a concept, documentation, design, and finally the part engineers tend to be most excited about: writing code.
Last year, we found another problem worth looking into.
This time, it was about Terraform and cloud infrastructure costs.
Terraform looked pretty great
We started looking into the problems faced by people working with Terraform.
For anyone who hasn't used it, Terraform is a tool for defining and managing infrastructure through code. Instead of manually creating cloud resources through a web interface, you describe what you need in configuration files and let Terraform handle the infrastructure changes.
Need a virtual machine? Define it.
Need a database, a network, and a bunch of other resources? Define those, too.
Your infrastructure becomes something you can version, review, and manage like the rest of your code.
We spent some time experimenting with Terraform ourselves, and honestly, it turned out to be a really convenient way to work with infrastructure.
There was just one catch.
It's relatively easy to define infrastructure in code. Understanding how much that infrastructure will cost is a different problem.
And that difference can get expensive.
*The problem: infrastructure code doesn't come with a price tag
*
Imagine you're working on a new project.
You define a few compute resources, add storage, configure a database, and set up networking. Everything looks reasonable in your Terraform files. The code passes review, the configuration looks clean, and you're ready to deploy.
But how much will it cost?
You can look up cloud provider pricing, inspect individual services, estimate usage, and calculate the numbers yourself.
If you know the infrastructure well, you can probably get a decent estimate. If you don't, you'll need to learn how the different resources are priced and how their configurations affect the bill.
And even if you know what you're doing, it's easy to miss something.
A configuration change might introduce a more expensive resource. Increasing capacity might change the monthly estimate. A seemingly harmless adjustment could affect several components of the infrastructure.
You can deploy first and inspect the bill later.
That's certainly one way to learn.
It's also the kind of lesson that tends to arrive with an invoice.
What if you could check the cost before deploying?
That was the problem we wanted to explore.
Terraform lets you describe the infrastructure you want to create. We wanted to make it easier to understand the financial consequences of that configuration before committing to the deployment.
Not after the resources are running. Not after the invoice arrives. Before.
That's the idea behind IaC Cost Tracker.
It analyzes Terraform configurations and estimates the associated cloud infrastructure costs. You can inspect the projected expenses, look at individual resources, and experiment with configuration variables to understand how different choices affect the total.
For example, instead of wondering whether changing a configuration will make your infrastructure more expensive, you can compare the projected costs of different configurations before deploying them.
The same idea applies when reviewing changes over time. Comparing infrastructure costs across commits helps you see how the financial impact of your code evolves alongside the code itself.
The goal isn't to replace Terraform or change how engineers build infrastructure.
It's to add one more piece of information to the process: what this infrastructure is likely to cost.
The earlier you find the problem, the easier it is to fix
There's a familiar pattern in software development.
The earlier you discover a problem, the more options you usually have to deal with it.
The same applies to infrastructure costs.
Before deployment, you can still change the configuration, compare alternatives, or reconsider whether you need a particular resource at all. After deployment, you may have to investigate running resources, coordinate changes, and figure out how to reduce spending without breaking anything.
Cost analysis doesn't magically make infrastructure cheap. It doesn't replace engineering judgment, either.
But it can help answer an important question before a change reaches production: Do we understand the cost implications of what we're about to deploy?
That seemed like a problem worth solving.
Another product, another real problem
Looking back, the process was similar to what happened with our LLM Cost Tracker.
We didn't start by asking, "What product should we build next?"
We started by looking for a problem.
Then we explored the technology, tried to understand the workflow, and worked out how a tool could make that workflow easier. The concept came first, followed by documentation, design, and implementation.
That's a much less glamorous origin story than having a brilliant idea in the shower.
But it's probably a more useful one.
Terraform is a great tool. Infrastructure as Code makes infrastructure easier to define, review, and manage. We just saw an opportunity to make one part of that workflow less painful: understanding the cost before the infrastructure goes live.
Because managing infrastructure is complicated enough.
Finding out how much it costs shouldn't have to be a surprise.
Top comments (0)