When I joined Autobutler as Tech Lead in 2022, they were spending 3M DKK annually on AWS. The founders knew something was off, but couldn't pinpoint exactly what. Velocity was slowing down, servers were crashing at night, and the team had grown to 11 engineers but shipping had actually gotten harder.
The first thing I did? I spent a week just watching. Monitoring dashboards, AWS bills broken down by service, deployment logs, database slow query logs. What I found was classic over-provisioning and zero caching strategy.
The infrastructure was massively oversized
They were running way too many servers for the actual traffic. The application was a Rails monolith with a React frontend—solid architecture, but it was drowning in unnecessary resources. Every time something felt slow, the previous team had just added more servers.
We spent six months methodically fixing things:
- Infrastructure consolidation through vertical scaling and proper load balancing. Turns out you don't need dozens of small instances when a few properly sized ones work better.
- Multi-level caching with Redis. Fragment caching for views, low-level caching for expensive database queries, and proper cache invalidation strategies.
- Database query optimization. Hundreds of inefficient queries, missing indexes on frequently queried columns, and zero strategy for expensive operations.
- Deployment pipeline rebuild. Modern containerization cut deploy times from 45 minutes to 8 minutes.
- Proper monitoring. Error tracking and performance monitoring so we could actually see what was breaking before users complained.
The team was also bloated
Here's the uncomfortable truth: they had too many engineers. We went from 11 to 4 through natural attrition, and velocity actually improved. Smaller team meant less coordination overhead, better code reviews, faster decisions.
I know this sounds counterintuitive, but at a certain point adding more people slows you down. Every new person needs context. Every decision needs more meetings. Every code review takes longer because more people want input.
The results
After six months: 2M+ DKK saved annually (infrastructure plus reduced team costs). Response times improved significantly. Deployment went from 45 minutes to 8 minutes. And the founders could finally sleep through the night without getting woken up by server crash alerts.
Key takeaway
Most infrastructure cost problems aren't solved by rewriting your application or switching to a "modern" stack. They're solved by understanding what you actually need, measuring what's slow, and fixing those specific bottlenecks.
What you should do first
If your infrastructure costs feel out of control, start here:
- Profile everything for a week. Don't guess. Look at your actual usage patterns, slow queries, error rates, and traffic distribution.
- Add caching strategically. Most Rails apps can cut database load by 60-80% with smart caching. Start with expensive queries.
- Rightsize your infrastructure. Look at actual CPU and memory usage. Chances are you're paying for resources you never use.
- Fix deployment pipeline. Long deploys mean less frequent deploys which means bigger, riskier changes. Make it fast.
You don't need to do everything at once. Pick the biggest pain point and fix that first. Then move to the next one.
Need help optimizing your infrastructure costs? We do this regularly for growing companies. Book a call and we'll walk through your setup.