Hook
Your AWS bill keeps climbing, and nobody on your team can explain why. You started at $3,000 a month. Then $5,000. Now $8,000. The engineering team says they need bigger servers. More memory. A new caching layer. Maybe a migration to Kubernetes.
I have heard this story dozens of times. And in most cases, the real problem is not your infrastructure. It is your code.
This is the story of how I joined a European SaaS company called Cuez, found that their API was doing 10x more work than necessary on every single request, and fixed it. The result: their AWS bill dropped by roughly 40%, and their API went from 3-second response times to 300 milliseconds.
No infrastructure migration. No new cloud vendor. No expensive DevOps hire. Just a senior engineer going through the codebase with a fine-tooth comb.
TL;DR Summary
- Cuez, a B2B SaaS platform for managing TV shows and live events, was burning through AWS resources because of inefficient code, not because they needed bigger servers.
- I audited the full codebase, identified unnecessary database queries, outdated libraries, and redundant processing that was eating compute time.
- After optimizing queries, implementing proper caching, removing dead code, and upgrading the framework, their API response time dropped from 3 seconds to 300ms.
- Infrastructure costs fell by approximately 40% because the servers were doing less unnecessary work.
- The whole process took about 4 months of focused engineering work.
Need a hand with your website or web app?
Free 30-min strategy call. I'll review your situation and give you a clear next step.
Table of contents
- The client and the problem
- Why your AWS bill is probably a code problem
- How I diagnosed the waste
- The four fixes that saved 40%
- The results in numbers
- How to tell if you are overpaying for cloud
- FAQ
The client and the problem
Cuez is a SaaS product built by Tinkerlist, a Belgian company. Their platform helps television producers and live event managers run complex shows. Think of it as project management software, but for the chaotic world of live TV. Multiple people collaborate in real-time, and the system needs to be fast because live events do not wait for loading spinners.
When I joined the team in 2021, the product worked. Users could create shows, manage rundowns, coordinate teams. But it was slow. Pages took several seconds to load. The API, built on Laravel (a PHP framework), was averaging 3-second response times.
The team had already tried the obvious fix: throwing more hardware at the problem. They scaled up their AWS instances. Added more memory. Provisioned bigger database servers. The bill kept going up, but the performance barely improved.
This is a pattern I see constantly with startups and mid-size SaaS companies. When your application is slow, the instinct is to buy bigger machines. But if your code is making the database do unnecessary work on every request, a faster database just does that unnecessary work slightly quicker. You are paying more to be inefficient faster.
Why your AWS bill is probably a code problem
Here is something most cloud consultants will not tell you: for the majority of SaaS applications processing under 10,000 requests per minute, your infrastructure is probably fine. Your code is the bottleneck.
AWS charges you based on compute time, data transfer, database operations, and storage. If your application is running inefficient database queries, loading libraries it does not use, or processing data it does not need, you are paying Amazon to waste electricity on your behalf.
I have seen this pattern across 250+ projects in 16 years of building software. The company assumes they have an infrastructure problem. They hire a DevOps engineer or an AWS consultant who recommends reserved instances, spot instances, or a migration to a different service. Sometimes that helps. But if the root cause is application-level waste, you are optimizing the wrong layer.
Think of it like a delivery truck with a broken GPS that drives twice the distance for every delivery. You could buy a more fuel-efficient truck. Or you could fix the GPS. One costs $60,000. The other costs a few hours of a mechanic's time.
At Cuez, the GPS was broken.
How I diagnosed the waste
My process was not glamorous. There was no AI-powered monitoring dashboard or proprietary scanning tool. I read the code.
Step 1: Full codebase audit
I went through the entire Laravel application, file by file. I was looking for:
Database queries that ran on every request but did not need to. These are the silent killers. A single unnecessary query might take 50 milliseconds, but if it runs on every API call and you handle 1,000 requests per minute, that is 50,000 milliseconds of wasted database time per minute.
Outdated libraries and dependencies. Cuez had accumulated packages over years of development. Some were no longer used. Others had been replaced by built-in framework features. Each one added startup time and memory usage.
Custom code that reinvented the wheel. Developers had written custom implementations for things that Laravel already handled natively. These custom versions were often slower and less optimized than the framework's built-in solutions.
Missing caching. Data that rarely changed was being fetched from the database on every request instead of being cached in memory.
Step 2: Profiling the hot paths
Not all code matters equally. I used Laravel's built-in query logging and profiling tools to identify which API endpoints were the slowest and which consumed the most database resources. This is where the 80/20 rule applies: about 20% of the endpoints were responsible for 80% of the server load.
The main rundown endpoint (the core screen where TV producers manage their show) was the worst offender. It loaded the show data, all segments, all associated media, user permissions, and collaboration state. Every piece of that data came from a separate database query, and many of those queries fetched more columns and rows than the frontend actually needed.
Step 3: Mapping the waste to dollars
I estimated how much each inefficiency was costing in AWS resources. This step matters because it lets you prioritize fixes by financial impact rather than just technical elegance. A query that wastes $500/month in compute gets fixed before one that wastes $20/month, even if the second one is technically more interesting to optimize.
The four fixes that saved 40%
Fix 1: Query optimization
This was the biggest win. I rewrote the most expensive database queries to fetch only the data the application actually needed.
The original code used what developers call "eager loading" in a wasteful way. It fetched entire related data sets when the frontend only needed a few fields. Imagine asking a librarian for every book in the building when you just need the titles from one shelf.
I restructured queries to:
- Select only the columns the frontend used
- Add proper database indexes so the database could find rows without scanning entire tables
- Combine multiple small queries into single, efficient ones where possible
- Remove queries that fetched data the endpoint never actually returned
On the main rundown endpoint alone, this cut the number of database queries from over 40 per request down to about 12.
Fix 2: Implementing proper caching
Some data changes rarely. User permissions, show configurations, and media metadata do not change between most requests. But the application was fetching all of this from the database every single time.
I implemented a caching layer using Redis (a fast, in-memory data store that AWS offers as a managed service called ElastiCache). Data that changed infrequently got cached with appropriate expiration times. When a user updated their permissions, the cache invalidated. Otherwise, the application pulled from memory instead of hitting the database.
This reduced database load substantially. Fewer database queries means your RDS instance (the AWS database service) works less, which means you either need a smaller instance or your existing instance handles more traffic.
Fix 3: Removing dead code and outdated dependencies
Over years of development, the Cuez codebase had accumulated unused packages. Some were npm packages that had been tried and abandoned. Others were PHP libraries that had been superseded by newer Laravel features.
I removed every package the application did not actively use. I replaced custom-written code with Laravel's built-in equivalents, which are maintained by a large open-source community and typically better optimized.
This reduced the application's memory footprint and startup time. On AWS, memory usage directly affects your bill. If your application uses 2GB of RAM per instance instead of 4GB, you can run smaller (cheaper) instances or fit more application processes on the same server.
Fix 4: Framework upgrade
Cuez was running on an older version of Laravel. I upgraded it to Laravel 10, which included performance improvements in the framework's core. The framework handles database connections, routing, and request processing, so a faster framework means every single request benefits.
I also upgraded Vue.js from version 2 to version 3 on the frontend. Vue 3 has a smaller bundle size and a faster rendering engine, which reduced the amount of JavaScript the user's browser had to download and execute. Less data transfer from your CDN means lower AWS CloudFront costs.
The results in numbers
After about four months of this work, here is where things landed:
| Metric | Before | After | Change |
|---|---|---|---|
| Average API response time | 3,000ms | 300ms | 90% faster |
| Database queries per request (main endpoint) | 40+ | ~12 | 70% fewer |
| Monthly AWS infrastructure cost | Baseline | ~60% of baseline | ~40% reduction |
| Application memory usage | High | Reduced | Smaller instances viable |
| User-facing page load | Several seconds | Sub-second | Dramatically faster |
The 40% cost reduction came from a combination of factors: fewer database operations meant a smaller RDS instance was sufficient. Lower memory usage meant smaller EC2 instances. Reduced data transfer from optimized API responses and smaller frontend bundles lowered CloudFront and bandwidth charges.
But here is what surprised even me: the performance improvement had a business impact beyond cost savings. The product team reported that user engagement went up after the speed improvements. Features that users had been avoiding because of slow load times started getting used. The sales team could demo the product without awkward waits.
A faster product is not just cheaper to run. It is easier to sell.
For context on why speed matters so much for business outcomes, I wrote a detailed breakdown in Website Speed Optimization: Every Second Matters, including data on how each second of load time affects conversion rates.
How to tell if you are overpaying for cloud
You do not need to hire someone like me to figure out if you have this problem. Here are five signs your AWS bill is inflated by code issues rather than genuine infrastructure needs:
1. Your bill keeps growing faster than your user base. If your monthly active users grew 20% but your AWS bill grew 60%, something is scaling poorly. Healthy applications have roughly linear cost scaling.
2. Scaling up servers did not help performance. If you moved to a bigger EC2 instance or RDS instance and response times barely changed, the bottleneck is your application, not your hardware.
3. Your database CPU stays above 70%. High sustained database CPU usually means inefficient queries are grinding away. A well-optimized application should keep database CPU under 40% during normal traffic.
4. Nobody on your team can explain what is driving the cost. If your engineering team cannot point to specific services and say "this costs X because of Y," you likely have waste hiding in plain sight. AWS Cost Explorer can help, but someone needs to interpret it.
5. Your application has not had a performance audit in over a year. Code accumulates inefficiencies over time. New features get rushed out. Quick fixes become permanent. Dependencies go stale. Without periodic audits, waste compounds.
If three or more of these sound familiar, you probably have a meaningful optimization opportunity. In my experience, most SaaS applications that have never been optimized are leaving 20-40% of their cloud spend on the table.
When to bring in outside help
You might be thinking: "My team should be able to do this." Maybe. But there are a few reasons an outside engineer often gets better results:
Fresh eyes catch what familiarity misses. Your team wrote the code. They have context about why decisions were made, but that same context creates blind spots. They may not question a pattern they implemented themselves six months ago.
Dedicated focus matters. Your engineers are building features, fixing bugs, and handling support escalations. Optimization work requires sustained, uninterrupted focus. An external engineer comes in with one job: find and fix the waste.
It pays for itself quickly. If your AWS bill is $10,000/month and optimization reduces it by 30%, that is $3,000/month in savings, or $36,000 per year. A focused optimization engagement typically pays for itself within the first quarter.
This is a core part of what I do as a fractional CTO and through my custom application development work. I come in, audit the system, fix what is costing you money, and set up practices so the waste does not come back.
If this sounds like your situation, let's talk about what an audit would look like for your stack.
FAQ
How long does a cloud cost optimization project take?
It depends on the size of your codebase and how many services you are running on AWS. For a typical SaaS application with a single API and database, a thorough audit takes 2-4 weeks. Implementing the fixes takes another 4-8 weeks depending on how much refactoring is needed. The Cuez project was about 4 months total because we also upgraded the framework version.
Can I reduce AWS costs without changing my code?
Partially. You can save 20-30% through reserved instances, savings plans, and right-sizing your servers. AWS Cost Explorer and Compute Optimizer will help with that. But the biggest savings come from making your application use fewer resources per request, which requires code changes. The two approaches work best together.
How much can I realistically save?
For applications that have never been optimized, 20-40% is common. I have seen savings as high as 60% in extreme cases where the codebase had years of accumulated inefficiency. If your application has already been through a performance audit recently, the remaining gains will be smaller, maybe 10-15%.
Will optimization break my application?
It can if done carelessly. Every change I made at Cuez went through code review, automated testing, and staged rollouts. Query optimizations were verified against production data patterns before deployment. Caching was implemented with proper invalidation so users never saw stale data. The risk is real but manageable with proper engineering practices.
Should I optimize or migrate to a different cloud provider?
Optimize first, almost always. If your application has inefficient code, it will be inefficient on any cloud provider. Google Cloud and Azure are not meaningfully cheaper than AWS for most workloads. Fix your application, then evaluate whether a provider switch makes sense for other reasons like specific managed services, pricing models, or geographic requirements.
What about serverless? Would moving to Lambda reduce costs?
Serverless (AWS Lambda) charges per execution rather than per hour, so it can be cheaper for applications with variable traffic. But Lambda has its own cost traps. If your code is inefficient, each Lambda invocation runs longer and costs more. You are still paying for compute time. Fix the code first, then evaluate whether serverless makes sense for your traffic pattern.
Do I need a DevOps engineer or a software engineer for this?
Both skill sets help, but for the kind of optimization I did at Cuez, you need a software engineer who understands your application framework deeply. A DevOps engineer can right-size your infrastructure and set up monitoring, but they typically will not refactor your database queries or upgrade your framework. Ideally, you want someone who can do both, which is why fractional CTO engagements work well for this kind of project.
About the author
I am Adriano Junior, a senior software engineer with 16 years of experience and an MBA in economics. I have worked on 250+ projects across SaaS, fintech, and e-commerce, including companies like bolttech ($1B+ valuation) and Cuez/Tinkerlist in Belgium. I help founders and CEOs reduce their cloud costs, fix slow applications, and make better technical decisions without needing to understand the technical details. Reach out if your AWS bill is keeping you up at night.
