FinOps for East African fintechs — cutting cloud spend without slowing delivery

The pattern in this region is distinctive. Fintechs here live and die by mobile-money rails, and mobile-money traffic is spiky by nature — M-PESA callback bursts at month-end, payday, and promotion windows can multiply request volume within minutes. Teams respond the only way that feels safe under pressure: provision for the worst burst they have ever seen, then leave that capacity running all month, just in case.

Two other forces make it worse. First, most cloud billing is in US dollars while revenue is largely in shillings, so every swing in the exchange rate quietly reprices your infrastructure — a bill that looks flat in dollars can grow uncomfortably in KES terms. Second, data transfer is the classic surprise line: cross-region replication, chatty microservices talking across availability zones, and analytics pipelines pulling raw data out of the cloud all bill by the gigabyte, and nobody notices until the invoice lands.

Before touching a single instance, make the bill legible. Tag everything — by service, by team, by environment — and enforce the tags at provisioning time rather than in a spreadsheet after the fact. Untagged resources should be the exception that gets chased, not the norm that gets ignored. Once allocation works, the numbers stop being an ops problem and become a product conversation: this feature costs this much to run.

Then put thirty minutes in the calendar every week. Same people, same dashboard: what moved since last week, and why? That is the entire ritual. Teams routinely find idle capacity, forgotten proof-of-concept environments, and oversized databases in the first few sessions — not because anyone was careless, but because nobody had ever looked with the bill open. The weekly rhythm matters more than the tooling; a shared spreadsheet reviewed consistently beats a sophisticated FinOps platform nobody opens.

With visibility in place, the quick wins are usually mechanical. Compare what each instance is provisioned for against what it actually uses over a representative month — including your busiest burst window — and size to reality plus sensible headroom, not to fear. Most cloud providers now surface right-sizing recommendations for free; the work is reviewing them with someone who knows the workload, not generating them.

Development and test environments deserve special attention. They rarely need to exist at 3 a.m. or over the weekend, yet they are commonly billed for every hour of the month. A simple shutdown schedule for non-production — evenings and weekends off — removes roughly two-thirds of those hours without anyone noticing during the working day. Storage follows the same logic: logs, snapshots, and old backups accumulate on premium tiers by default. Set lifecycle rules that move ageing data to colder, cheaper tiers automatically, and decide deliberately what you actually need to retain and for how long — your regulator and your incident-response plan should drive that answer, not the default settings.

The deepest savings come from designing for your real traffic shape. If your load is bursty — and for mobile-money workloads it almost always is — autoscaling is the honest answer to the “just in case” instinct: hold a modest baseline, scale out when the callbacks surge, scale back in when they pass. Getting there usually means fixing the things that stop scaling from working, such as state held in application memory or startup times measured in minutes; that engineering effort pays for itself quickly.

Be honest, too, about what you self-host. Running your own database, queue, or Kubernetes control plane looks cheaper per hour, but the true cost includes patching, backups, failover drills, and the engineer-weeks all of that consumes. For a lean fintech team, managed services are very often the cheaper option once people-time is counted. And once your baseline usage has been stable for a few months — not before — commit to it: reserved instances and savings plans exchange flexibility you were not using for a meaningful discount on the capacity you run around the clock. The mistake we see is committing early, while the architecture is still moving; let the baseline settle first.

A word of caution, because we work both sides of this. When finance pressure arrives, the first candidates for deletion are often security tooling, backups, and observability — precisely because their value is invisible when everything is fine. Resist that. A trimmed logging pipeline saves a little every month until the day you need to reconstruct an incident and cannot. Skipped backup storage is the cheapest line on the bill right up until ransomware arrives. Cut waste aggressively; do not cut your ability to detect, investigate, and recover. If a control genuinely costs too much, redesign it — shorter hot retention with cold archive, sampled traces with full error capture — rather than switching it off.

None of this needs a transformation programme. Here is where we would start:

• Book the weekly 30-minute cost review — same people, every week, bill open.
• Turn on cost allocation and tag your top ten resources by spend before Friday.
• Schedule non-production environments to shut down on evenings and weekends.
• Pull your provider’s right-sizing recommendations and action the three largest.
• List every self-hosted service and ask honestly what each costs in engineer-time.

Do those five things and you will know, within a month, where your money goes and which of the deeper levers is worth pulling next. If you would like a second pair of eyes on your bill or your architecture, that is exactly the kind of engagement our cloud practice runs — no drama, just the numbers and a plan.