Your Infrastructure Bill Could Be Drastically Lower

You could probably pay far less in server costs if you stopped subsidising your developer's complexity addiction.

Kubernetes clusters. Load balancers. Multi-region failover. A managed database with read replicas. A Redis instance for caching. Multiple separate queue service for background jobs. An infrastructure bill with 15 line items.

For an app that could run on a single ~$50-a-month server and one database.

How this happens

It usually starts with good intentions. The developer or agency building the app wants to "do it right". They've read the blog posts, man.

Every piece of the puzzle gets its own dedicated service. The database does the data. Redis does the caching. Multiple services for queues and workers. Monitoring gets its own platform. Logging gets its own platform. Each service has its own configuration, its own cost, its own failure modes.

The result is infrastructure that's technically impressive and completely inappropriate. Like hiring a fleet of armoured trucks to deliver a sandwich. The sandwich arrives safely, but you did not need the armoured trucks.

Resume-driven infrastructure

Engineers like building complex systems. Setting up a Kubernetes cluster is interesting. Configuring a multi-service deployment pipeline is satisfying. Running everything through a single database and web service on a managed platform? That's boring. Nobody writes a blog post about that.

So the infrastructure grows. A Redis instance gets added because "you need a proper cache". A separate queue gets spun up because "background jobs shouldn't share resources with your database". A load balancer gets configured in front of a single server that's running at 3% CPU utilisation. Each addition sounds reasonable in isolation. Together, they add up to an AWS bill that creeps from $50 to $500 to $2,000 to $5,000, and nobody questions it because the setup looks "professional."

The agency, meanwhile, has no incentive to simplify. More infrastructure means more billable hours to manage it. More complexity means the client can't easily switch to someone else. And the monthly bill isn't the agency's problem, it's yours.

What most apps actually need

Most applications are not Netflix. Most applications will never have a scaling problem, despite what many engineers will tell you.

A well-configured single server, with a single database, in a monolith codebase can comfortably handle many, many thousands of concurrent users. The one database can handle your caching, your job queue, and your WebSocket connections without needing separate services for any of them.

We do this with one of our own SaaS platforms, Hooroo.ai. One web service, one database. Those two things handle the web requests, queue, workers, cache, web sockets, and the production data. It has hundreds of users, and processes thousands of phone calls every day, in addition to users clicking around in the UI. Not to mention, our marketing site is on the same single web service, so all traffic to the marketing site itself is included in that. We pay $50/month and it does over $10k MRR. (This doesn't include our AI services, by the way. Those are separately handled by external API's.

The app has never gone down. Not once. It just works.

The instinct to separate everything into dedicated services comes from a good place. At Netflix scale, you absolutely need dedicated infrastructure for each concern. At 500 daily users, or 5,000, or even 50,000, you almost certainly don't. You're paying for complexity that solves a problem you don't have.

For most products, the entire infrastructure could be: one server or managed platform, one database, one deployment pipeline.

Total cost: $20 to $200 a month. Not $2,000 to $5,000.

"But what about when we scale?"

This is the justification every time. "We need this infrastructure so we're ready when we grow."

Two things about that.

First, you almost certainly won't need it. The overwhelming majority of software products never hit the scale where dedicated queue workers and caching layers become necessary. Building for a scaling problem you don't have (and statistically won't have) is spending real money on an imaginary problem.

Second, that's a problem you can solve once it exists. When your database actually starts struggling under load, that's when you add replicas. When your background jobs genuinely start affecting app performance, that's when you spin up a dedicated worker. You scale infrastructure in response to evidence, not in anticipation of growth that may never come.

The complexity tax

Over-engineered infrastructure doesn't just cost more to run. It costs more to maintain, more to debug, and more to understand.

When something breaks in a system with 8 interconnected services, finding the problem is an archaeology project. Is it the queue? The cache? A network policy? A misconfigured environment variable in one of 6 deployment configs? Logs are scattered across platforms. Context is fragmented. A 10-minute fix turns into a 3-hour investigation just figuring out where the problem lives.

When your entire stack is one server and one database, you check the logs. One place. One context. One deployment. You find the problem and fix it.

Every piece of unnecessary infrastructure is another thing that can fail, another thing that needs monitoring, another thing that needs updating, and another line on your monthly bill. Complexity compounds.

Complexity also fights your AI tools

AI coding tools like Claude Code and Cursor work best when they can see the whole application in one place. They need full context to make good decisions: how the data model fits together, how the business logic flows, where a change in one place affects another.

A single codebase in a single repo gives an AI tool complete visibility. It can trace a bug from the API endpoint through the business logic to the database query. It can make a change to the order flow and update every affected file, because it can see all of them.

When your application is fragmented across multiple repos and services, the AI can only see one piece at a time. It can't trace a problem across service boundaries. It can't make a holistic fix that touches the user logic, the payment logic, and the notification logic in one pass. Every cross-service change becomes a manual coordination exercise, which is exactly the kind of slow, expensive work that AI tools are supposed to eliminate.

In a world where AI-driven development is compressing the cost of building and maintaining software by 10 to 20x, your infrastructure should be working with those tools, not against them.

What we actually set up for clients

Most Launch Assembly projects run on infrastructure that costs between $20 and $200 a month. A single managed platform. A single database that handles everything. Sensible defaults. Nothing exotic.

When a client comes to us already running a $3,000-a-month setup, we'll usually audit it and consolidate. More often than not, we can strip out 70% to 90% of the services without losing anything meaningful. The app runs the same. The users notice nothing. The bill drops by an order of magnitude.

The right amount of infrastructure is the least that works

Good engineering is about using the right tools, not every tool. And for most products, the right infrastructure is boring, simple, and cheap.

If your cloud bill has more than 4 or 5 line items on it, someone should be asking why. If your architecture diagram needs a legend, something has gone wrong. If you're paying for a Redis instance and your app has 200 users, you're solving a problem that doesn't exist.

Simple infrastructure is faster to deploy, easier to maintain, cheaper to run, and more reliable than the gold-plated alternative. The only thing it doesn't do is look impressive on an architecture blog.