dodo payments

designing the rails for global monetization

setting the stage

dodo payments is building the rails for global monetisation - a system that lets developers, indie hackers, and early-stage companies accept money from anywhere in the world. teams use dodo payments to create subscriptions, usage-based products, and one-time purchases; offer local payment methods across countries; and automate tax through a merchant-of-record model.

the ambition is simple:
make global monetisation stupidly easy.

as the founding product designer, I shape every part of the product experience. the work sits somewhere between definition and execution: deciding what the product should be, and then designing how it should feel.

what’s inside this case study

this case study is a collection of small, focused pieces of work from different parts of dodo. each one looks at a specific moment in the product — where clarity was missing, where friction slowed teams down, or where complex systems needed a simpler expression.

the scope will change as the product grows, but the purpose stays the same:
to show how design shapes the experience of making money globally.

understanding the space

monetisation isn’t hard because of UI. it’s hard because of everything underneath it.

developers have to deal with scattered payment method rules, fast-changing tax regulations, complex compliance flows, inconsistent billing patterns, and integration paths that break easily. early-stage teams often want to ship monetisation quickly, but the underlying system makes the process slow, confusing, and fragile.

the design challenge is to make a dense, global financial system feel approachable for teams moving fast.

constraints that shaped the work

dodo payments operates in a space where:

  • compliance requirements shift constantly

  • technical decisions have real financial consequences

  • developer expectations are high

  • startup pace leaves no room for slow cycles

  • clarity directly affects merchant trust

design has to absorb complexity, not expose it.

my role

as the founding product designer, I own:

  • product structure and information architecture

  • end-to-end flows across all core features

  • visual direction and consistency

  • design systems and reusable patterns

  • developer guidance and integration clarity

  • collaboration with engineering, founders, compliance, and support

how i design at dodo payments

designing at dodo starts with real signals — support tickets, discord threads, intercom chats, and emails from merchants trying to ship fast. patterns in these conversations reveal where the product feels unclear, where flows break, and where we’re slowing people down. those signals shape what we build next.

from there, the work is about turning that noise into structure: flows that are easier to understand, interfaces that reduce friction, and systems that feel predictable even when the underlying logic is complex.

the pace is quick. engineering ships fast, compliance rules evolve constantly, and merchants expect clarity immediately. design has to move with that pace while keeping the experience steady and trustworthy.

mini case studies

the sections that follow are small snapshots from the above mentioned process — the moments where design helped make global monetisation feel lighter and more usable.

1

1

1

designing trust without friction: rethinking onboarding and payouts

a redesign of Dodo Payments’ onboarding and payout experience to help developers activate faster, while keeping trust and compliance invisible but strong.

2

2

2

designing a clearer way for customers to manage their bills

the original billing portal surfaced the right information, but the experience felt dense and hard to navigate. i redesigned it to make invoices, payments, and subscription details easier for customers to understand at a glance, with clearer hierarchy and fewer points of friction.