Why we built Invoicr around bank transfers, not card fees
Three months before launch, our first beta tester - a plumber in Manchester - sent me a message that stuck. 'Why are you making me pay 2.5% to get paid?' He was holding an invoice in his hand, watching Stripe take a chunk, and asking a question that should have had an obvious answer. It didn't. Not at the time.
The math that changed our direction
I started MRVL Technologies because I got tired of watching small tradespeople fight with software built for people who weren't them. Plumbers, electricians, decorators - the backbone of the UK economy - were using invoicing tools designed for consultants in coffee shops. But the real friction I kept hearing about wasn't the design. It was the fees.
A £500 invoice on a card processor costs around £12.50. That's not a rounding error for someone working alone. It's lunch for the week. It's fuel. It's the difference between a job feeling worth your time and a job that leaves you short at the end of the month.
When we looked at UK open banking, the numbers flipped. The same £500 invoice costs around £4. We aren't taking a percentage cut at all. The fee is flat, transparent, and buried beneath the line where it belongs.
But here's the thing: open banking is harder to build with. Card processors have been perfected by thousands of companies over two decades. They're the safe choice. We chose the harder path because the maths made sense for our users, not because it was convenient for us.
Why we didn't go the obvious route
We could have launched with Stripe or Square. Everyone does. The infrastructure exists. The integrations are documented. The sales pitch writes itself: 'Accept card payments from your clients.' Simple, proven, profitable.
What nobody mentions is that you're profitable by taking a slice of your customers' money. You're asking a plasterer to pay you so you can take 2.5% and hand the rest to him. That relationship felt wrong from day one.
The harder truth: most UK tradespeople don't want to offer card payments anyway. They want to get paid. Fast. Into their bank account. No middle layers, no waiting for batch settlements, no dispute windows. Bank transfer - direct, immediate, final - is the default.
So we built around it. We integrated with UK open banking so clients can pay you bank-to-bank straight from the invoice link. No card reader, no terminal, no percentage cut. The payment goes through in seconds, and you see it land.
It meant learning new infrastructure. It meant launching only in the UK instead of chasing global scale. It meant saying no to features that would have looked impressive in a demo but felt hollow for our audience. But it meant building something honest.
The risk we took (and why it paid off)
In month two of beta, we had a real moment of doubt. A prospect asked why we didn't offer card payments as an option. 'My clients expect it,' he said. We didn't have a good answer at the time. So we built the feature, quietly, knowing it would cannibalize our own product story.
It didn't. Of the hundreds of invoices sent through Invoicr since launch, roughly 8 in 10 clients choose bank transfer. They don't want to reach for a card. They want the path of least resistance, which happens to be the cheapest path.
The risk wasn't that we were wrong about the maths. The risk was that we were wrong about our users. We weren't. UK tradespeople care about speed and simplicity and keeping their money. Open banking delivers all three.
Launching bank-to-bank as the flagship payment method also shaped every other decision we made. We went mobile-first because tradespeople work on site, not at desks. We kept the free tier generous because we wanted real users, not contact forms. We built the client portal with a single URL token so your customer doesn't need to log in. Bank-to-bank paid for that philosophy. It forced us to design for actual friction, not theoretical convenience.
What this means if you're building solo
If you're a plumber, electrician, or decorator using Invoicr, the maths are straightforward. On a £500 invoice, you pocket an extra £8.50 compared to a card processor. On a hundred invoices a month, that's £850. On a thousand, it's £8,500. For a sole trader, that's real money.
But it's not really about the fee. It's about the philosophy. We chose to build around what works for you instead of what extracts the most value from you. That choice cascaded through everything else we built. It's why the free tier gives you 5 invoices and 3 customers - real people, not signups. It's why Pro is £9.99 a month, not £29. It's why we support VAT and CIS compliance without upselling you into a 'premium' tier.
The card processor path was always available. It would have been easier. It would have attracted different customers. But it would have meant starting with the assumption that we wanted a piece of your money. We don't. We want you to keep it.
The question nobody asked but we kept asking ourselves
About halfway through building, someone asked me: 'If bank-to-bank is so good, why doesn't everyone do it?' Fair question. The answer is that it's UK-specific, it requires deeper compliance work, and it doesn't scale the same way a card processor scales globally. It's also not flashy. You can't put 'Accept payments from 180 countries' on the homepage. You can put 'Pay 0.8% instead of 2.5%,' but that feels small until you actually do the work of sending invoices week after week.
We chose depth over breadth. We chose the UK market instead of global ambition. We chose to be useful to someone real - a plumber with a van and a phone - rather than chase every possible use case.
Most software companies don't make that choice. Most build what's most profitable to build, then find the customer afterwards. We did it backwards. We found the customer first and built what they actually needed.
A year on, that plumber from Manchester is still using Invoicr. He's never mentioned the fee again. Instead, he asked if we could send reminders via WhatsApp. We added it. Because that's what happens when you stop asking how much you can take and start asking what would actually make the job easier.