The Penny Problem Nobody Talks About
Three weeks before launch, our lead backend engineer flagged something that would have been invisible to most users: every single transaction in Seedr needed to be stored as an integer. No floating-point decimals. No rounding errors. Just whole pence, always.
The Day We Realized We Were Building a Payment Platform
When we started Seedr, we thought of it as a tipping SDK. Drop three lines of code into Streamr or Giggl or Foundr, let your audience send you a quick tip, and move on. Simple, right?
Then we started talking to actual creators. A church organist in Manchester. A Christian podcast team in London. A faith-based content maker in Glasgow. And we realized something: the moment you touch money, you're not building a toy. You're building financial infrastructure.
That's when the conversation with our compliance advisor changed everything. She wasn't interested in our app flow or our UI. She wanted to know: how are you storing pence? How do you audit a transaction? What happens if there's a dispute? And crucially, can you prove, to the Financial Conduct Authority, that you never lost a single penny to a rounding error?
That's when we made the call: everything in Seedr would be stored as integers. 500 Seeds equals £5.00, stored as 500 in the database. Not 5.00. Not 5.0000000001. Just the integer. When a creator tips another creator, or a fan tips a streamer, the math happens in whole pence. No decimals. No surprises.
Why This Matters More Than You'd Think
Most creators don't care about the backend schema. Fair enough. But they should care about one thing: can they trust that every penny their audience sends actually reaches them?
Floating-point arithmetic is how tiny errors compound. A transaction here, a rounding there, and suddenly you've got £0.0000001 sitting in limbo somewhere. Multiply that across thousands of tips, and you've got real money vanishing into the digital ether. It's not unique to Seedr. It's a problem across fintech.
But we decided early: not on our watch. Every fee, every payout, every transaction amount lives in our Supabase backend as an integer. We even centralized all fee logic in a single source of truth: supabase/functions/_shared/fees.ts. One place. No drift. No version mismatches.
Why? Because when the FCA comes knocking (and we're building toward FCA Payment Institution authorisation by 2028), we need to hand them an audit trail they can read without a calculator. Here's tip from User A to Creator B. Here's the 5% fee (or 1.5% if that creator is Foundr Free, or 1% if they're Foundr Pro). Here's what hit the creator's account, down to the last pence. All integers. All traceable.
The Three-Line Embed That Meant Months of Thinking
On the surface, Seedr looks effortless. You drop the SeedrButton into your Swift or Kotlin app. Three lines. Your users tap it, see a tipping UI, and send £5 (minimum) directly via Stripe Connect. No account creation. No friction.
That simplicity cost us. We spent weeks arguing about how to handle the minimum tip amount. Why £5? Because at that level, the payment processing is clean, the Stripe fees are proportional, and we avoid the trap of becoming a micro-payment platform where transaction costs eat the actual tip.
But there's something else hidden in those three lines: trust. Your fans are sending real money through your MRVL app. They don't think about whether the backend is using integers or floats. But they absolutely notice if their tip never reaches you, or if it lands as £4.97 instead of £5.
That integer architecture, boring as it is, is the difference between a tipping button that feels safe and one that feels sketchy. It's the difference between a creator dashboard that shows you exactly what you earned on Monday, and one that has rounding discrepancies you have to chase down.
Why Creators in Faith Communities Forced Us to Get This Right
Our first creators were church musicians, Christian podcasters, and faith content makers. That community has deep roots in trust. If you're asking someone to support your ministry through a digital platform, every transaction matters theologically and practically.
A church organist in Manchester told us: 'I need to know that if someone tips me £50 to support a community project, that £50 reaches the project. I can't have decimal dust and rounding errors eating away at something that matters to people's faith.' She was right. And she wasn't being paranoid. She was being wise.
So INTEGER pence became our principle. Not just a backend detail. A promise. Every tip, stored as whole pence. Every fee calculated on integers. Every payout to a creator's Stripe Connect account, mathematically certain.
It also meant that when we build creator dashboards and analytics, the numbers are clean. You can read your dashboard on a Monday morning, see exactly what you earned, and move forward. No floating-point ghosts. No 'why is this £0.003 short?' conversations.
The Unsexy Work That Matters
Building Seedr taught us that some of the most important decisions in fintech aren't flashy. Nobody will ever tweet about our integer architecture. No TechCrunch piece will headline 'Creator Tipping SDK Uses Whole Pence Database Design'. It's not a feature you demo.
But it is the reason we sleep well knowing that when the FCA eventually reviews our Payment Institution application in 2028, we'll hand them four years of perfect, traceable, integer-based transaction records. It's the reason a creator can trust that their Monday payout is accurate to the penny. It's the reason we can honestly say that Seedr, even in Phase 1, is built like a real payment platform from the ground up, not bolted on afterward.
The MRVL creator ecosystem spans Streamr, Giggl, Foundr, and their audiences. Each of those creators deserves tipping infrastructure that was thought through, not rushed. That was our bet. And it started with a conversation about pence.
Most fintech platforms compromise on trust somewhere in the stack. Where did you last notice a company making the boring choice instead of the flashy one, and did it change how you felt about them?