What Five-Country Credit Rollouts Taught Me About Platform Design

What Five-Country Credit Rollouts Taught Me About Platform Design

When you ship a credit platform in one country, you build a product. When you ship it in five — India, Singapore, Oman, the Philippines, and Indonesia — you build a contract with the future. Every assumption you bake in becomes a knot somebody has to untie at 2 a.m. for the next launch.

I learned this the hard way at M2P, where we re-architected the Credit Card Management System to support consumer cards, corporate cards, line of credit, and BNPL on a single platform. Here are the three lessons I'd hand a younger me.

Configuration is a product, not a feature

The temptation in any new geography is to fork. The local regulator wants a quirky reporting field, the local issuer wants a different fee schedule, and the engineering team — already stretched — quietly creates a branch. Six months later you have five products masquerading as one.

The discipline I now hold sacred: every country variation has to be expressible as configuration. If it can't be, the platform itself needs a new primitive — not a fork. Fee structures, dispute timelines, statement formats, settlement cycles: each of these is its own configurable surface, owned by product, reviewed like any other release.

The longest pole in the tent is the regulator

Engineers like to build for the happy path. Product managers like to ship. Regulators care about neither. In credit, the regulator is the longest pole in the tent — and pretending otherwise is how you turn a six-week launch into a six-month one.

We started routing every new market launch through a regulatory readiness checklist *before* engineering scoped the work. Reporting formats, KYC tiers, transaction limits, customer-disclosure language — all of it tagged to specific platform capabilities. The conversation with engineering changed from "what should we build?" to "which existing capability handles this, and what's the gap?"

The 14-process automation rule

We automated 14+ processes — write-off and settlement, accounting, dispute resolution, regulatory reporting — and saved 6,400+ person-days a year. The headline metric is impressive; the lesson behind it is duller.

Every one of those processes was once a Jira-ticket-and-Excel-sheet ritual. They got automated only when product treated them as first-class roadmap items, not as ops debt. The instinct in product is to chase the next launch. The discipline is to look at the team behind you — the ops team running settlements at midnight — and ask which of their rituals deserves to be replaced by the platform.

A platform is a series of unmade decisions

The best platforms I've worked on weren't the ones with the longest feature list. They were the ones where the team had said *no* to enough one-off requests that the architecture stayed coherent. Every "yes" to a special case is a "no" to the speed of the next launch.

When I look at a roadmap now, I read it backwards: what aren't we building, and is that the right thing to skip? That's where the real design work happens.