Building for Contributors, Not Just Treasuries: A Product Philosophy

Most payment infrastructure gets designed from the top down. Start with the organization, the treasury, the dashboard the finance lead will stare at every month, and work outward from there. The contributor, the person actually receiving the payment, becomes an afterthought, a line item that the system eventually gets around to handling. We built Fundable the other way around, and it's changed almost every decision we've made.

Two very different users, one shared system

A DAO treasurer and a contributor in Lagos are using the same platform, but they're having almost entirely different experiences with it. The treasurer wants visibility, control, and confidence that spending follows the rules they've set. The contributor wants their money, quickly, in a form they can actually use, without needing to understand multi-signature approvals or vesting cliffs to get there.

It's tempting to optimize heavily for the treasurer, because the treasurer is usually the one signing the contract, choosing the platform, and championing it internally. But if the contributor's experience is an afterthought, the whole system eventually breaks down anyway. A platform that delights treasurers and frustrates contributors will get replaced the moment contributors start complaining loudly enough. So we treat both as first-class users, with equal weight in how we prioritize what gets built next.

What this looks like when we're deciding what to build

Every feature on our roadmap gets asked the same uncomfortable question: who does this actually help, and does it help the other side too?

Multi-signature approvals protect the organization. Fine, necessary, but on their own they do nothing for the contributor waiting to get paid. So alongside that, we built claim functionality that's fast and simple, because an organization's governance shouldn't translate into a contributor's delay.

Batch payroll via CSV saves a treasurer hours of manual work. Good. But if the underlying claim and cash-out experience for each of those contributors is still slow or confusing, we've optimized one half of the transaction and ignored the other. So the work doesn't stop at "the organization can now pay 100 people in one upload." It continues through to "and each of those 100 people can convert their earnings into local currency in minutes."

This is also why cash-out sits as one of our four core pillars instead of being treated as a downstream integration. If we only thought about treasuries, offramp would be someone else's problem to solve. We don't think it should be anyone's problem, anywhere in the chain.

Why this is a harder way to build, on purpose

It would be simpler to build exclusively for the treasurer. Treasurers are the ones in the room during sales conversations. They're the ones reading the FRD, evaluating the dashboard, comparing us against competitors. Contributors mostly never see a product comparison. They just experience the result.

But that asymmetry is exactly why it's easy for contributor experience to quietly degrade across the industry. Nobody's in the room advocating for them during a vendor evaluation, so the incentive to build well for them is weaker unless someone deliberately holds that line.

We hold it because we think it's the right thing to do, and also because we think it's the smarter long-term bet. Contributors talk to each other. A contributor who has a frustrating cash-out experience tells their peers, and eventually that feedback finds its way back to the treasurer who chose the platform. The two user groups aren't as separate as the org chart suggests.

The standard we're trying to meet

A platform built only for the people managing money will eventually fail the people receiving it. A platform built only for the people receiving money will struggle to get organizations to adopt it at all. We're trying to build for both, simultaneously, without treating either as the secondary audience.

That means every roadmap decision gets weighed against two different kinds of success: did this make the organization's job easier, and did this make a real person's payday better. If a feature only answers one of those questions, it's not finished yet.