Three lines of code. One button. How SeedrButton works.

The moment we realised embedding should be stupid simple

Seedr started as an idea: creators in the MRVL ecosystem should be able to accept tips from their audience in real time. Not monthly subscriptions. Not Patreon-style memberships. Just a moment. A viewer watches a Streamr stream, enjoys it, sends a tip. A Foundr maker ships something, gets support. A Giggl comedian lands a joke, gets paid for it.

But we kept hearing the same thing from our early testers: the integration was friction. They'd have to drop into documentation, wrestle with callbacks, figure out which SDK they were using. Swift or Kotlin. Different surfaces, different questions.

That's when it clicked. If tipping was meant to be casual for fans, it had to be casual for creators too. Embedding SeedrButton shouldn't require an engineering sprint. We rewrote the integration. Three lines became the target. Three lines became the design constraint.

What actually happens when you paste those three lines

A creator opens their MRVL app codebase. They import SeedrButton. They drop it into their view. That's it. No API keys to hunt down. No webhook URLs to configure. No environment variables to mess with. The button connects directly to Stripe Connect on the fan's side, handles the transaction, and routes the tip to the creator's account.

The minimum tip is £5. That matters. It means you're not managing micro-transactions at the penny level. Fans aren't tipping 50p. They're making a real choice to support someone. And creators aren't chasing 200 tips a week; they're watching meaningful support roll in.

When a fan taps the button, they don't need to create an account. They just pay. That's the whole design. Get in, support the creator, move on. The Supabase backend records it, Stripe handles the money, and at the end of the week, every Monday morning, the creator gets paid.

Why the backend had to be built before the button

We spent months designing Seedr's schema before we wrote the SDK. This wasn't about being pedantic. It was about FCA compliance.

Every transaction in Seedr is recorded in integer pence. No floating point nonsense. No rounding errors that compound over thousands of tips. Why? Because we're building toward Payment Institution authorisation by 2028. When that happens, the audit trail has to be bulletproof. A regulator shouldn't have to ask a single question about how a transaction landed in someone's account.

That's why the platform fee structure exists the way it does. Standalone creators pay 5%. But if you're part of Foundr, the fee drops to 1.5% for Free members, 1% for Pro. That's baked into the schema. There's a single source of truth. Not scattered across spreadsheets or different codebases. One place. supabase/functions/_shared/fees.ts. When a tip comes in, the fee is calculated the same way, every time.

The three-line integration only works because the backend is right. Creators can embed a button with confidence knowing that money will move correctly, every time, every week.

Who this solves for, and how we found them first

Our beachhead is faith creators. Church communities. Christian content makers on Streamr. These are people who weren't asking for a Patreon alternative. They were asking for a way to accept support without friction, without a monthly commitment from their audience.

A pastor streaming a sermon on Streamr. A church musician posting on Giggl. A Christian author sharing work on Foundr. Their audiences want to support them. But not with a monthly subscription. With a tip. Right now. After something resonates.

The three-line embedding matters to them because they're often not engineers. They're creators. They work with developers, yes, but they don't want to be bottlenecked by integration work. They want to turn it on and move on.

That's how we tested it early. We put SeedrButton in front of these creators first, watched how they used it, and only when we saw them embedding it without asking questions did we know we'd got the design right.

The weekly payout, the analytics dashboard, the web profile

SeedrButton is one surface. But Seedr has three. Every creator gets a web profile at seedr.app/@handle. A clean, personal landing page where fans can send tips, see the creator's profile, understand who they're supporting. No branding friction. No MRVL logo noise. Just the creator.

The creator dashboard is where the money story lives. You see every tip that came in. You see which fans tipped. You see the arc of your earnings over weeks. And every Monday morning, if you've hit the £20 minimum payout threshold, money moves to your bank account via Stripe Connect. No waiting for a monthly cycle. No surprise holds. Just predictable, weekly payouts.

For creators on Foundr, there's Creator Pro. £4.99 a month or £39.99 a year. It unlocks deeper analytics. Branded customisation. The tools that creators who've been tipped consistently want to go deeper with their data. But Seedr itself is free to set up. The cost is the platform fee. You only pay when someone tips you.

Why we're not FCA-authorised yet, and why that matters less than you'd think

I see this question come up: if you're aiming for Payment Institution authorisation, why launch now? The answer is that Stripe Connect is already FCA-authorised. We're running on its licence, which means the money side is solid. What we're building toward is our own licence, our own phase 3. That's coming by 2028. But right now, creators are getting paid correctly, fans are sending tips securely, and the audit trail is clean enough that regulators won't blink when we apply.

The schema is FCA-ready. The fees are auditable. The transactions are in pence, not floating point. Everything we do now is a rehearsal for the day we hold our own payment licence. That's why the integration is clean. That's why the backend was designed first. We're not building fast and loose. We're building for regulation, which means we're building to last.