Designing a credit system without becoming the bank
Moloco Commerce Media's first in-platform billing and credit experience, made legible and built to scale.
Role:
Senior Product Designer (sole designer, end to end)
Team:
1 PM & 5 ENG
Timeline:
~3 months
Client, third-party tools, and screens are withheld or reconstructed and generalized to respect confidentiality. The problem framing, decisions, and system are representative of the work I led.
The problem
Billing on Moloco Commerce Media ran on three models at once, prepaid (a set cap), postpaid (pay later), and credit, but none of it was visible inside the product. To see spend, track credit, or reconcile a discrepancy, operators and advertisers had to leave for a complex third-party tool that dumped every level of data at once, with no tailoring to who was looking. The work started as a billing dashboard and was reprioritized to credits, where the demand was growing fastest.
The tension
The production system only let credit be assigned per ad account, one account at a time, with no bulk apply and no way to target a specific campaign. Every campaign under an account drew from one shared pool, first come, first served, exactly what our biggest stakeholder did not want, since they needed to control credit by campaign and region. Underneath sat a scope question: how much of a credit system to build, given Moloco isn't resourced to own anyone's money.
The hardest decision
The lead engineer pushed to build the credit system out fully up front. His argument was to support any future need now, pointing to Meta's flexible money system as the model and wanting to bend our legacy system to get there fast with AI. He was persistent, so rather than overrule him, my PM and I pressure-tested the idea: I built mockups, my PM pulled usage data and gathered input from teammates close to customers, and it kept coming back that the added complexity wasn't worth it and customers didn't need it yet. My position was to build for validated needs and scale when they materialize, not over-engineer for a hypothetical future, and the data backed it. Modifying legacy would also break the experience for the majority who rely on it, so we kept legacy stable and built a new version people can migrate to when ready. On scope, the cleanest path was to show the data and let platforms manage their own billing; I reframed the engineer's expiration and scheduling asks as bounded promotional credits, and resolved the edge cases the fast plan ignored, like which credit is spent first and how to allow per-campaign assignment without breaking the per-account majority.
The system
A standalone credit experience, built as a new version alongside untouched legacy. Near-term: a credit dashboard at the ad-account level (credit set, spent, available) that can assign credit to individual campaigns and in bulk, solving the first-come-first-served limitation. Long-term: a north-star vision, assignment to specific campaigns or an entire ad account, promotional credits (durations, target accounts, auto-expiry), and a migration path from legacy, used to inspire and scope the next quarter of work. To ground both, I worked with my PM to validate the near- and long-term needs with current and prospective customers looking to onboard with Moloco Commerce, and benchmarked against how other ad-tech platforms handle credit.
Impact
I specced both models and built the long-term north-star mock, which was approved for engineering feasibility, and we kicked off the roadmap to build toward it. The work aligned stakeholders on a validated, prioritized plan, and my edge-case analysis and the legacy-versus-new call kept the team from over-building or destabilizing existing users.
What I'd change today
I'd bring engineering and the key stakeholder into the framing sessions earlier, so we settled the build-everything-now versus build-for-validated-needs debate before it took several rounds of back-and-forth to resolve.