The right recommendation is often to spend less.
A long-running client's monthly cloud bill had drifted higher than the traffic on their site justified. The honest recommendation wasn't to optimise inside the architecture. It was to leave it. Here's the trade-off, and what taking that call cost the account short-term.
The bill that didn't fit the traffic
One of the accounts we've built for since our earliest days runs a group of solar businesses. Somewhere in year three, the monthly cloud invoice for their web platform had grown to a figure in the tens of thousands of rupees a month. The site itself is a product catalogue and a lead form. It gets steady traffic, but it is not a real-time application. The infrastructure had been sized for a workload the business didn't actually have.
What 'optimise the bill' would have meant
There's always a version of the answer that keeps everyone busy. We could have picked reserved instances, rewritten a couple of jobs, tuned the load balancer, and clawed back twenty or thirty percent. That work would have taken weeks. The bill would have come down. The architecture would still have been the wrong shape for the workload — just less wastefully wrong.
What we recommended instead
We told them to leave the architecture. The site's traffic pattern was almost entirely read-heavy; the content updated infrequently; there was no reason for a running application server at all. We rebuilt the site as a prerendered static set with a small mail handler behind it, and moved it to a shared cloud plan sized for the actual traffic. Monthly infrastructure cost dropped from the tens-of-thousands range to a small fraction of that.
What it cost us
The AMC on the old stack ended when the old stack did. For a period, the account was smaller than it had been for years — no monthly retainer to pay for optimisation work we'd just told them not to do. There was a real gap in what the client spent with us, and we felt it.
Why we still think it was right
Two reasons. First, we couldn't in good conscience recommend keeping infrastructure the traffic didn't warrant just because the retainer paid our rent. Second — and this became the practical answer to the short-term hit — the client re-engaged us later at the smaller shape and has stayed. Recommendations that save the client money get remembered. Recommendations that don't quietly become the reason a client eventually leaves.
The rule we came away with
Every infrastructure review we do now starts with the traffic first, not the current architecture. If the current shape doesn't match what the traffic actually is, the right recommendation is almost always to leave, not to optimise. We say this out loud even when it's inconvenient for us.