There's a movement happening right now, and I'm here for most of it.
Companies are canceling SaaS subscriptions. Engineering teams are building internal replacements. CTOs are looking at their vendor bills and saying, "We could build that." Some of them are even right.
But here's what nobody's talking about: the cloud bill for the thing you built to replace the thing you were paying for.
I saw a thread blow up last week — a well-known engineer arguing that most software can be replaced with something built in-house. Build the shed. Own it. Control your destiny. And the crowd went wild.
They're not wrong. A $500/month SaaS tool that your team has outgrown? Kill it. Build something that does exactly what you need. Ship it on a Friday afternoon. Feel great about yourself.
Here's what happens next.
That internal tool gets deployed to EC2. Nobody right-sizes the instance because "it's just internal." It gets an m5.xlarge because that's what the last three things got. It's running in a single AZ with an ALB in front of it that nobody will ever decommission. There are CloudWatch logs set to NEVER EXPIRE because the engineer who deployed it doesn't know that's not the default. The EBS volume is gp3, 500GB, because someone figured they'd need room to grow. They're at 12GB.
Six months later, that internal tool is costing $2,100/month.
You saved $500/month on the SaaS bill. You're spending $2,100/month on the replacement. And nobody knows, because "it's just infrastructure" buried in a shared account.
I see this constantly.
This isn't just about small internal tools. It's the same pattern at scale.
The cloud repatriation narrative has been building for three years. DHH pulled Basecamp out of AWS and wrote a book about it. Every CTO who read it did the math on a napkin during their next board meeting.
Some of these moves make perfect sense. Predictable, steady-state workloads with known capacity requirements? Colo might genuinely save you 60%. I'm not going to argue with the math when the math works.
But for every company that successfully repatriates a workload, I've seen five that try the hybrid approach — keep some things in cloud, move some things on-prem, build some things from scratch — and end up spending more because:
1. They lose visibility. Your FinOps tooling was built for cloud. The moment you go hybrid, you're stitching together three different cost models with duct tape and a spreadsheet.
2. Nobody owns the "internal" costs. When it was a SaaS bill, finance saw it. When it's compute and storage spread across six AWS services, it's invisible until someone runs a query that nobody's scheduled to run.
3. The ancillary services multiply. You moved the app off Heroku. Congratulations. But now you need a load balancer, a managed database, a CI/CD pipeline, monitoring, log aggregation, and a deployment process. Each one is "only" $50-200/month. Together they're $1,500/month for infrastructure that Heroku was giving you for $400.
4. Engineers don't optimize things they built. This is the killer. When you're paying a vendor, there's natural pressure to evaluate the spend. When it's your team's code running on your team's infrastructure, it becomes identity. Criticizing the cost feels like criticizing the work.
The build-vs-buy debate is almost always framed as: "What does the vendor charge vs. what would it cost us to build?"
That's the wrong question. The right question is: "What will it cost us to run this thing for the next three years, and who is going to be accountable for that number?"
Because the build cost is a one-time event. The run cost is forever.
I've worked with a Series B startup that built an internal analytics platform to replace Looker. The Looker bill was $48K/year. They were sick of it. Their data team built a beautiful replacement in about six weeks. Great work. Genuinely impressive engineering.
The replacement ran on a cluster of r5.2xlarge instances with a managed Postgres database, a Redis cache, and an S3 bucket that was accumulating 200GB/month of intermediate query results that nobody was lifecycling. Eighteen months in, they were spending $87K/year on infrastructure for their "free" analytics platform.
Nobody noticed for eleven months because the cost was spread across Compute, RDS, ElastiCache, and S3. It didn't show up as a line item that said "Looker replacement." It showed up as infrastructure. And infrastructure is somebody else's problem.
I'm not anti-build. I'm anti-build-without-a-cost-owner.
If you're going to replace a SaaS tool or repatriate a workload, here's the minimum:
Tag it on day one. Not "we'll get to tagging later." Day one. Every resource that supports this workload gets a tag that lets you run a Cost Explorer query and see the true cost of ownership.project:looker-replacement or whatever you want. Just make it queryable.
Set a budget alarm. Before you deploy. Not after. The number should be less than what you were paying the vendor, because that was the whole point. If the alarm fires in month two, that's a gift — you caught it early.
Assign an owner who isn't the builder. The person who built it will never objectively evaluate its cost. That's human nature. Have someone else — a FinOps practitioner, a team lead, literally anyone with access to the billing console — review the spend quarterly.
Include operational costs in the original business case. When your CTO says "we can build that for $30K in engineering time," ask: "And what's the projected annual run cost?" If the answer is a shrug, the business case is incomplete.
Here's the thing — the build-vs-buy math can absolutely work in your favor. I've seen teams replace $200K/year SaaS contracts with internal tools running on $40K/year of well-optimized infrastructure. That's real money. That's a legitimate competitive advantage.
The difference between the teams that save money and the teams that accidentally spend more? The winners treated the cloud infrastructure like a product with a P&L. The losers treated it like a free resource that came with their AWS account.
Your shed might be brilliant. But if nobody's tracking the electric bill, the water bill, and the property tax, you don't actually know if it's cheaper than renting.
The cloud doesn't care whether you're running a vendor's code or your own. It charges by the hour either way.
---
Drowning in cloud costs you can't trace back to a decision? Book a free 30-minute strategy call and we'll find the sheds nobody's paying attention to.
