FinOps for African fintechs: A practical playbook
Cloud spend is a quiet line on most African fintech P&Ls until it isn't. By the time it's a problem, the architecture decisions are already made. Here's the operating playbook we install before that day arrives.
Most fintechs we've consulted in the last three years had a cloud bill that grew faster than their revenue, then plateaued at a level that quietly ate 12–18% of gross margin. None of them planned for that. All of them could have avoided it.
FinOps is not a tool. It's an operating practice. Here's the version we install at African fintechs specifically — adapted for currency volatility, payment-network costs, and the absence of mature reserved-instance markets in some regions.
Stage 1: Visibility — get the data before you negotiate
You cannot optimise what you cannot see. Before any architecture change:
- Tag everything: enforce a tagging policy (environment, service, product, owner) via IaC. Untagged resources alert.
- Allocate by product line, not just by service. The board asks "what does Card cost us?" — you need to answer in dollars per active card.
- Daily dashboards, not monthly. The lag between an unbounded query and a $40k bill shock is 48 hours, not 30 days.
- Per-environment quotas: dev/staging budgets enforced, not advisory. The number-one source of surprise spend is a dev environment that no one turned off.
This stage costs nothing but discipline. It usually exposes 15–25% of spend that was no one's job to optimise.
Stage 2: Architecture levers
Once you can see what costs what, most savings come from three architectural levers, in this order of payback:
a) Right-size before you reserve
Reserved Instances and Savings Plans only pay off if the underlying capacity is correctly sized. We've audited fintechs that had committed to 3-year RIs on over-provisioned compute. They locked in inefficiency.
Right-size first. Look at p95 utilisation over 4 weeks. If you're under 40%, downsize. Compute is the easiest place to start.
b) Storage class hygiene
S3 (or equivalent) is where forgotten money lives. Transaction logs from 2022 sitting in Standard storage cost roughly 4× what they'd cost in Glacier Deep Archive. Lifecycle policies are a one-day project that pay back forever.
Common policy that works for fintechs:
- 0–30 days: Standard (live access for reconciliation)
- 30–90 days: Standard-Infrequent (audit access)
- 90 days – 7 years: Glacier (regulatory retention)
- 7+ years: Deep Archive or deletion if compliance allows
c) Egress is the silent killer
Cross-region data transfer, NAT gateway charges, and CDN egress dwarf compute on many fintechs we've audited. Specifically:
- VPC peering or PrivateLink instead of cross-AZ public-IP traffic
- Regional caches in front of databases that get hot reads from many services
- Carefully chosen CDN tiers — the price-per-TB at the second pricing tier is often a third of the first
Stage 3: Negotiation and commitment
Only after right-sizing and storage hygiene do RIs and Savings Plans pay off. For African fintechs specifically:
- USD-denominate the commitment, but model in local currency. Naira and cedi volatility can wipe out a 30% RI discount in a bad quarter. Run the scenario.
- Prefer Savings Plans to RIs. Flexibility matters more than the marginal 4–6% extra discount RIs offer.
- Use shorter commitments for new business lines, longer for stable workloads. A 3-year commitment on a 6-month-old product is gambling.
Stage 4: Operating cadence
FinOps as a one-off project is theatre. It's an operating practice:
- Monthly FinOps review with finance + engineering + product
- A named FinOps lead with explicit decision rights
- Quarterly architecture review against the cost dashboard
- Cost regressions flagged in the same channel as functional regressions
The teams that get this right typically reduce cloud spend by 28–40% in the first year and hold the reduction in year two. The teams that treat it as a one-time exercise rebound to 85% of original spend within 18 months.
What's specific about African fintechs
Three things that don't show up in the standard AWS FinOps playbook:
- Currency hedging for committed compute. Naira-denominated revenue against USD-denominated infrastructure is a real risk. Talk to your treasurer before signing.
- Local data residency requirements — both NDPR and central-bank guidelines — sometimes force region choices that aren't cost-optimal. Bake the constraint into your architecture, then optimise within it.
- Payment network costs are not infrastructure but feel like it on the bill. Don't confuse the two; the optimisation levers are completely different.
The bottom line
FinOps doesn't require a separate team or expensive tooling. It requires visibility, three architectural levers applied in the right order, and a monthly cadence. The fintechs who install this before they need it are the ones who scale margin alongside revenue. The fintechs who wait are the ones whose CFO calls us in panic the week before the board meeting.
If you'd like an honest look at your cloud bill, we run a one-week assessment that produces a prioritised optimisation roadmap. We don't sell tools, we don't take a percentage — just a flat fee.
15 years across payments, telco, and platform engineering. Founded Hexcore to prove African engineering can ship at world-class standards.
Three boxes, three jobs: API gateway, load balancer, and reverse proxy
Half the architecture reviews we sit in conflate these three components — and that confusion shows up later as over-engineered infrastructure or under-engineered traffic management. Here's the honest distinction, the decision framework we use at Hexcore, and the patterns we ship in production.
The four practices that turn a launch into a durable product
Most launches succeed. Most products fail soon after. The gap is not engineering talent — it's a set of operating practices that the strongest teams treat as defaults. Here are the four we install on every Hexcore engagement.
Boring on purpose: why Go quietly won the modern backend
Go was never the fashionable choice. It was always the durable one. Here's why we reach for Go first when we're building backend services that have to last — and the specific patterns we use to keep them clean as the codebase grows.