Why we built SeedrButton into every MRVL app

The problem was friction, not intention

Creators and their audiences wanted to support each other. The intent was there. What was missing was a frictionless way to do it.

If we'd built Seedr as a standalone product, we'd have solved half the problem. Creators would have a payout dashboard. Audiences would have a place to tip. But the moment of genuine connection, the one that actually matters, would still be in a different place entirely. Your audience is watching you on Streamr. Why should they leave Streamr to tip you?

We spent weeks mapping the user journey. Every step outside the creator's native app was a step lost. Browser switching on mobile. Login pages. Friction. By the time someone completed a tip journey on a separate site, the emotional weight of that moment had dissolved.

The insight was obvious once we saw it: the button had to live where the connection happens.

Three lines. Not three hundred.

Embedding a payment SDK in native apps is technically straightforward if you're willing to accept complexity in implementation. We chose a different path. We built SeedrButton to integrate in Swift and Kotlin with three lines of code. That constraint was intentional.

Every extra line of code a developer has to write is a barrier to adoption. Our team spent months reducing our SDK surface area. We stripped away optional configurations. We made decisions about defaults that worked for 95 percent of use cases. We automated the plumbing so that integrating Seedr felt less like engineering a payment system and more like adding a visual element.

That philosophy extended to the backend too. No-account tipping means your audience doesn't need to create a profile, install another app, or remember credentials. They tap SeedrButton, sign in with Stripe (which they likely already know), and send a tip of 5 Seeds or more. The tip lands in your creator dashboard on Monday. That's it.

One backend, three surfaces

Seedr runs on a single Supabase backend that serves three surfaces: the embedded SeedrButton SDK inside Streamr, Giggl, and Foundr; a creator web profile at seedr.app/@handle; and the creator dashboard where you see analytics and manage payouts.

That unified architecture meant every architectural decision had to serve all three. We couldn't optimise for one surface at the expense of another. It also meant we had to make some early calls that would shape the product for years.

The tipping minimum is 5 Seeds, which is £5. The payout minimum is £20. Those numbers aren't arbitrary. We watched creator behaviour, looked at transaction costs, and made sure a creator could reach payout by getting just four tips. We use integer pence throughout the system. No rounding surprises. No floating point errors that compound over thousands of transactions.

Every fee decision is logged in a single source of truth in our codebase. 5% platform fee for standalone use; 1.5% if you're on Foundr Free; 1% if you're Foundr Pro. That transparency matters, especially when you're asking creators to trust you with money.

The faith creator beachhead

We launched Seedr into a specific community first. Faith creators. Church community members. Christian content makers on Streamr and Giggl. That wasn't a constraint. It was strategy.

Communities built on values move differently. They're not chasing vanity metrics. A pastor running a live prayer session cares about meaningful connection, not reach. The people watching care about supporting that work. The financial relationship is secondary to the spiritual one. That dynamic meant our product didn't need to be all things to all creators. It needed to work beautifully for a specific relationship.

Within that community, the numbers told us something important. Audiences were actually tipping. Not out of obligation. Out of genuine belief in the work. We saw repeat supporters. We saw communities coordinating to hit payout milestones together. We saw creators messaging us to say this was the first time their work had generated real income.

That beachhead effect proved the product worked. Then we built outward.

Building toward real regulation, not around it

Seedr is Phase 1 of the MRVL Pay roadmap. We're aiming for FCA Payment Institution authorisation by 2028. That sounds like a distant goal. It shapes every decision we make today.

We could have taken shortcuts. Built something faster, less compliant. Instead, we made early choices that future regulators will look at and understand immediately. Every transaction creates an audit trail in integer pence. We have AML thresholds built in. Manual review kicks in above £10,000. We use Stripe Connect, which is already FCA-authorised, as our current payment processor. Zero ambiguity about who holds the money.

That architecture takes longer to build. It's less glamorous than moving fast and moving money. But it's the difference between a product that will exist in five years and one that might face a regulatory wall and vanish.

One question we're still asking ourselves

We've built SeedrButton into three MRVL apps now. We've shipped weekly payouts. We've got creators earning real money from their communities. The technical problem is solved.

What we're still learning is the business one. Creator Pro, our optional analytics tier at £4.99 a month, exists for creators who want deeper insight into their supporters. But adoption tells us something worth thinking about: most creators, especially at the beginning, care far less about dashboards and far more about whether they can actually reach their next payout milestone.

As we think about what comes next, the constraint that mattered at the start still matters now. How do we keep making money flow more frictionless, not less? How do we make sure that the button in the app is always easier than the alternative?