Most of our new clients arrive with the answer already chosen. They have read the articles, watched the talks, and concluded that their next system has to be serverless, broken into many small pieces, and built around AI. The internet has told them that anything else is old-fashioned and risky. Our job is usually to slow that conversation down. These approaches are real, and in the right place they are excellent. They are also expensive, complicated, and the wrong shape for most of the businesses we work with. This post is how we actually decide.

---

The Hype, And Why It Lands

The pitch for serverless is hard to argue with at first hearing. You only pay for what you use. The system grows on its own when busy and shrinks to nothing when quiet. The provider takes care of keeping it running. The talks call it the future, and the cloud vendors agree.

The pitch for splitting an application into many small pieces is similar. Each team owns its part. Each piece can be changed independently. Failures stay contained. It sounds like the kind of thing a serious company should have.

The pitch for using AI in everything is the loudest of the three. Every competitor has it on their website. The fear of being left behind is doing a lot of the talking.

We understand why founders, operations leaders, and product owners arrive convinced. The arguments are real. They just leave out the parts that matter most for the size of business we usually work with: the shape of the cost, what happens when something breaks, the people who have to keep the system alive, and how easy it is to change suppliers later.

What Serverless Actually Buys You, And What It Costs

Serverless is, in plain terms, paying a cloud provider per use rather than per month. You stop paying for a fixed-size machine and start paying every time something happens. For a quiet system that occasionally springs to life, that trade is excellent. For a system that is busy every day, it is often a bad deal.

A few things that get learned the hard way:

• Surprise bills. When the price is tied to usage, a small mistake can scale the cost up enormously in a day. A loop that should have stopped, a busy customer, a mis-tuned setting. With a fixed-size system, the same mistake just makes the system slow. With usage-based pricing, it makes the bill big.
• Hidden delays. Systems that have been idle take a moment to wake up. For a customer waiting on a screen, that moment is visible. There are ways to remove the delay, but every one of them is another line on the invoice.
• Harder to change suppliers. Once an application is built around one cloud’s particular set of building blocks, moving to a different provider is no longer a switch. It is a rebuild. That is a strategic commitment, not a technical detail, and it should be made deliberately.
• More people, not fewer. The marketing implies you need less operational capability because the provider takes care of more. The reality is that the provider takes care of different things, and the team still needs to understand the platform deeply to keep costs and reliability in line.

None of this makes serverless a bad choice. It makes it a specific choice with specific consequences, and those consequences need to fit the business.

What “A Single System” Actually Means

When we say a single system, we do not mean something fragile sitting in a back room. We mean a well-built application running on infrastructure the team can understand and afford, with proper backups, monitoring, and a fast and predictable way to ship updates.

What that buys you, in business terms:

• A bill that does not surprise you. A monthly cost that is the same in a quiet week as in a busy one. Cash flow planning becomes possible.
• Faster changes. A new feature ships in minutes, not after a coordinated release across many separate parts.
• Easier to keep alive. When something goes wrong, there is one place to look. The team can fix it without spending the first hour working out which of the twenty pieces is at fault.
• Boring in a good way. The tools have been around for years. The people who can operate them are not rare or expensive. The supplier market is competitive.

For most internal tools, most subscription products serving business customers, most line-of-business applications, and most early-stage products that are still proving the idea, this is the shape that works. Not because it is fashionable. Because it is cheap to run, easy to change, and forgiving when the team is small.

The Trade-offs That Don’t Make the Conference Talks

A short, honest list of the things we have watched cost businesses real money when they chose the fashionable answer for the wrong reasons.

The shape of the cost matters more than the level. Usage-priced infrastructure is wonderful when usage is low. It is dangerous when a single mistake, a misbehaving customer, or an unexpected spike turns one day’s bill into a month’s budget. With a fixed-cost system, the same event simply makes the system briefly slow. We have seen companies receive single-day invoices that would have paid for a year of the alternative.

Splitting the application multiplies the work, not divides it. Every piece needs its own monitoring, its own deployment, its own contract with every other piece. This is a sound trade for a large company where many teams need to work without waiting on each other. It is a poor trade for a small business that simply wanted a faster product.

Vendor lock-in is a board-level decision. Building deeply on one cloud provider’s particular building blocks is a long-term commitment to that supplier. That can be the right call. It should be a deliberate one, not the result of a sales conversation. We have inherited several “we want to leave this cloud” projects where the answer was honest and uncomfortable: this is a rebuild, not a move.

AI everywhere is the same trap, one layer up. AI is a real tool with real value when the product genuinely benefits from it. Bolting it onto a workflow that does not need it adds delay, unpredictability, and a vendor bill, in exchange for a marketing tick. Customers who use the product every day notice the delay long before they notice the marketing.

Complexity is paid by your team. Every clever architecture choice is a tax on the people who keep the system running. Onboarding new staff takes longer. Incidents take longer to resolve. Holiday cover becomes harder. None of this appears in the conference talks, because the conference speaker is not the one being paged at 2am.

The decision isn't architectural — it's commercial. Start with the business constraints, not the tech.

How We Actually Decide

We start from five questions. The right answer almost always falls out once these are answered honestly.

1. What does demand look like? Steady, predictable traffic across the day points strongly toward a single, well-built system. Genuinely unpredictable bursts with long quiet periods between them are where pay-per-use approaches start to earn their keep. A spike once a month is not a reason to rebuild around them.

2. How big is the team that will run this? A small team should run a simple system. A complicated system on a small team becomes the team’s full-time job, and there is no time left for new features. A large company with dedicated platform people can absorb the complexity. A small one cannot.

3. How quickly do users expect a response? If a person is staring at a screen waiting, every delay matters. If the work is happening in the background, the user never sees the delay, and a slower-but-cheaper option becomes attractive.

4. What is the cost ceiling the business can absorb? A subscription product with thin margins needs a cost floor that is low and a cost ceiling that is knowable. A business that cannot tolerate a five-figure surprise should not adopt a model where a five-figure surprise is technically possible.

5. What is the realistic five-year picture? Most applications stay close to the size they are. The ones that grow rarely grow in the way that was predicted at the start. Designing today for an imagined future scale that may never arrive almost always costs more than the small amount of work needed to adjust later, once the real shape of the business is clear.

If the answers point to serverless, we use serverless. If they point to splitting the application, we split it. We have done both. They are not our default, because they are not the right default for most of the work we are asked to do.

When These Approaches Genuinely Win

To be specific, here are the cases where we recommend the fashionable answer without hedging.

• Pay-per-use infrastructure for genuinely bursty work. Processing a file when a customer uploads one. Sending a message when an external system pings yours. Running a job once a day. The provider is offering a ready-made tool, and renting it is cheaper than building it.
• Splitting the application when teams are blocking each other. Once two or three teams are tripping over each other’s work, splitting is worth the operational cost. Before that, it is cost in search of a problem.
• AI when AI is the product. A search that has to understand meaning, a draft generator, a summary feature, anywhere the AI output is what the customer is actually paying for. Decoration is not the same thing.

The Quiet Recommendation

Most of our clients do not need serverless. Most do not need their application split into many independent pieces. Most do not need AI in the path that customers wait on. They need a well-built system running on infrastructure the team understands, on a bill the finance department can plan around, with a process for shipping changes that takes minutes, and with a small group of people who can keep it running calmly.

That is not an exciting answer. It is the right one for far more businesses than the internet would have you believe.

If you are about to commission a new build and have arrived with the architecture already chosen, get in touch before the contracts are signed. Our development services include independent reviews of architecture decisions: no lock-in, no upsell, just an honest read on whether the approach you have been sold is the one your business actually needs.

Frequently Asked Questions

Is serverless always cheaper? No. It is cheaper for quiet, unpredictable workloads. For steady, day-to-day demand it is usually several times more expensive once everything is added up.

Do we need to split our application into many small services? Almost never at the start. Splitting is a way to let large teams move without blocking each other. With a small team, it is overhead with no real return.

When does serverless actually pay off commercially? When work arrives in unpredictable bursts, when small delays do not matter, and when the provider’s ready-made tools genuinely save you from building something yourself.

How do you decide for a specific client? We start with the business: shape of demand, cost ceiling, team that will run it, realistic five-year picture. Once those are clear, the right answer is usually obvious.

Daniel Z

Technical Lead · Two Red Kites

Technical Lead at Two Red Kites. Sits at the intersection of engineering and strategy: leading the team, setting technical direction, building internal developer tooling, and staying hands-on with the code across FinTech, HealthTech, Construction, and SaaS projects.