DEV Community: Ben Clifford

What "Single Source of Truth" Actually Means in Practice — A Look at Omnea's Data Architecture

Ben Clifford — Fri, 07 Aug 2026 07:04:41 +0000

"Single source of truth" gets thrown around in every SaaS pitch deck until it's basically meaningless. Omnea, a London based procurement platform, is a decent case study in what the phrase actually requires architecturally, because their core product depends on it working correctly across an entire company's finance stack.

The problem: supplier data lives everywhere except where you need it

Procurement data in most companies is scattered across spreadsheets, email threads, Slack messages, and half a dozen disconnected point solutions. Legal has one view of a vendor contract, finance has another, IT security has a third. None of them reconcile automatically.
That fragmentation isn't just annoying, it creates real risk: duplicate suppliers nobody notices, compliance gaps that surface only during an audit, and spend nobody can actually account for.

Omnea's pitch is that instead of bolting a dashboard on top of that mess, you need a continuously synced layer that pulls from and writes back to the systems finance, legal, and IT already use. That's a meaningfully harder engineering problem than a read only reporting tool.

The two-way sync problem

A one-way data pipeline (pull data in, display it) is comparatively easy. A two-way orchestration layer, where changes in your procurement platform propagate back out to the source systems and vice versa, is a different class of problem entirely.
You're now dealing with conflict resolution, race conditions between systems updating the same record, and the question of which system is authoritative when two updates disagree.

This is the unglamorous infrastructure work that decides whether a "single source of truth" claim is real or marketing. Any team building similar orchestration layers across multiple enterprise systems will recognize the shape of the problem: sync frequency versus API rate limits, partial failure handling when one downstream system is unreachable, and audit logging robust enough that when a discrepancy shows up, you can actually trace where it originated.

Why natural language intake is the easy part

The AI facing feature that gets the press attention is the natural language request intake, someone typing "I need to get this vendor approved" instead of filling out a form. That's the visible layer. It's also, relatively speaking, the easier engineering problem: parse intent, route to the right workflow.
The harder problem sitting underneath it is making sure that once the request is captured, the resulting data update is consistent, reconciled, and doesn't silently create a duplicate supplier record that undermines the entire premise of having one source of truth.

The takeaway

If you're building anything that claims to unify data across systems your users already use elsewhere, the marketing pitch and the actual engineering effort will diverge sharply. The dashboard is the 10% everyone sees.
The two-way sync, conflict resolution, and reconciliation logic underneath it is the 90% that determines whether the product actually works at scale, and it's exactly the kind of infrastructure problem that gets buried in most startup founder stories in favor of the AI feature that made the funding headline.

Building Retry Logic for Recurring Payments: What Failed Direct Debit Collections Teach You About Idempotency

Ben Clifford — Tue, 04 Aug 2026 07:20:07 +0000

Recurring billing is one of those systems that looks trivial in a demo and turns into a distributed-systems problem the moment it touches production. The core issue: payment rails fail in ways that aren't binary, and your retry logic needs to reflect that.

Why "just retry" isn't a strategy

With Direct Debit specifically, a failed collection can mean a few very different things: insufficient funds, an expired or cancelled mandate, an account that no longer exists, or a bank-side technical failure. Treating all of these the same way, retry in 24 hours, is how you end up hammering a dead mandate for weeks or, worse, retrying a payment that already technically succeeded on the bank's side but hasn't reported back yet.

A better mental model is to bucket failures:

Transient failures (technical error, timeout) → retry quickly, maybe within hours

Insufficient funds → retry, but with backoff timed around typical pay cycles rather than a fixed interval
Mandate invalid/cancelled → do not retry, surface it to the customer immediately
Duplicate/already processed → don't retry at all, this is where idempotency keys save you

Idempotency is not optional

Every payment initiation call should carry an idempotency key generated client-side, not server-side, so that a network timeout followed by a client retry doesn't create two charges. This matters more with bank rails than cards because the feedback loop is slower. If your API call times out on a Direct Debit submission, you genuinely don't know whether the bank received it. Retrying blind without an idempotency key means you might double-collect from a real customer's real bank account, which is a much worse failure mode than a failed card charge.

Webhooks as the source of truth

Polling for payment status works until it doesn't. The scalable pattern is to treat webhooks as your source of truth for state transitions (submitted → confirmed → paid, or submitted → failed → retried), and to build your system so it's resilient to webhooks arriving out of order or being delivered more than once. Store the event ID, dedupe on it, and never assume webhook delivery is exactly-once, because it almost never is in practice.

The dunning problem is a UX problem, not just a backend one

A surprising amount of churn in subscription businesses isn't voluntary cancellation, it's failed payments that never got resolved. If your retry logic silently fails three times and then cancels the subscription without ever nudging the customer, you're optimizing for backend simplicity at the cost of revenue. The systems that handle this well pair backend retry logic with proactive customer messaging, "your payment failed, update your details," timed to land before the account actually lapses.

None of this is unique to payments. It's the same class of problem as any system dealing with unreliable delivery, partial failure, and eventual consistency; payments just make the stakes for getting it wrong immediately visible in someone's bank balance.
It's also a recurring theme in startup founder stories: the unglamorous failure-handling work is usually what separates a subscription business that scales from one that quietly bleeds churn.

What UK Bootstrapped SaaS Founders Actually Pay for Business Banking

Ben Clifford — Sat, 01 Aug 2026 07:39:38 +0000

"Free business banking" is one of the most misleading phrases in UK fintech marketing. Every major digital bank advertises a free tier Starling, Tide, Mettle, Monzo, Revolut but "free" depends entirely on how many transfers you make, whether you invoice, and whether you touch foreign currency. Here's what five common bootstrapped-founder scenarios actually cost, worked out line by line.

Scenario 1: Solo SaaS founder, 10 transfers a month, no invoicing

You're paying a couple of contractors and a hosting bill. Nothing fancy.

Starling: £0. Unlimited free UK transfers, no monthly fee.
Mettle: £0. Same story, plus FreeAgent (~£150/year value) thrown in.
Monzo Lite: £0.
Tide: 5 transfers free, then 5 × £0.20 = £1/month.
Revolut: £10/month minimum (Basic plan fee applies regardless of volume).

At this volume, Starling, Mettle, and Monzo Lite are functionally tied at zero cost. Revolut is the expensive outlier here because you're paying for multi-currency capability you're not using.

Scenario 2: Invoice-heavy consultancy, 50 transfers a month, client invoicing

You bill clients directly and chase payments monthly.

Tide: 5 free transfers, then 45 × £0.20 = £9/month, plus 3 free invoices monthly (extra invoices need the paid Smart plan at £12.49/month if you exceed that).
Starling: £0 for transfers, but invoicing is a £7/month add-on — so roughly £7/month.
Monzo Pro: £9/month flat, invoicing included.
Mettle: £0, invoicing included via bundled FreeAgent the cheapest option if you don't need multi-user access or international payments.

For a solo consultancy that only invoices UK clients, Mettle wins on pure cost. The moment you need a second user or an international client, that calculus changes fast.

Scenario 3: Cash-heavy small retailer/market trader, £2,000/month in cash deposits

Starling: 0.7% at the Post Office, minimum £3 — on £2,000 that's £14/month.
Tide: 0.5% at Post Office (min £2.50) or 3% at PayPoint Post Office route costs £10/month, PayPoint costs £60.
Mettle: up to £500/day free at the Post Office, so £2,000 spread across the month can land at £0 if you deposit in smaller batches but confirm current terms directly with Mettle, as cash deposit policy details vary.
Monzo Lite: £500/month free, so anything above that starts incurring charges.

Cash-handling businesses should model this scenario specifically it's the one place "free" digital banking quietly becomes the most expensive option on the list.

Scenario 4: Exporting SaaS, billing US and EU clients in USD/EUR

Revolut: £10/month, but you get 25+ currencies at interbank rates for the first £1,000 monthly, then 0.6% FX on weekdays (1% weekends). For a founder converting say £5,000/month, that's roughly £10 + (0.6% × £4,000) = £34/month.
Starling: EUR add-on only, limited multi-currency workable for EU-only, not for USD.
Others: no meaningful multi-currency support, meaning you'd be paying your card processor's FX markup on top of a domestic-only account, which is typically a worse rate than Revolut's interbank pricing.

If you're actually invoicing in foreign currency every month, Revolut's £10 fee is usually cheaper than eating a worse FX spread elsewhere.

Scenario 5: Growth-stage, want lending headroom

Only one account on this list offers overdrafts and business lending as a fully licensed bank: Starling. Monzo Business also offers overdrafts and loans subject to credit checks.
Tide, Mettle, and Revolut don't offer overdrafts at all. If you're planning to need short-term credit as you scale, that's not a fee comparison it's a structural feature only some of these accounts have.

The actual lesson

None of these accounts is "cheap" or "expensive" in the abstract cost is a function of your transaction pattern, not the marketing page. Map your real monthly numbers (transfers, invoices, cash, foreign currency) against the scenario closest to yours before deciding, because the gap between the cheapest and most expensive option for your specific pattern can be £30-40 a month real money for a bootstrapped founder.
It's a small enough gap to get lost in the noise of running a business, but it's exactly the kind of detail that gets overlooked in most UK business news coverage of these accounts, which tends to stop at the headline "free" claim.

All fees and limits verified against provider websites as of mid-2026 banking fee structures change, so confirm current pricing before choosing an account.

Three Acquisitions, Three Different Jobs: How Allica Bank Built a £3.7B Loan Book by Buying, Not Building

Ben Clifford — Tue, 21 Jul 2026 09:40:02 +0000

Most companies build every feature themselves and treat acquisitions as a last resort. Allica Bank did the opposite. In four years it made three acquisitions, each solving a completely different problem, and turned a bank with almost no loan book into one holding £3.7 billion in loans. If you like thinking about buy vs. build decisions at the company level, this is a genuinely clean case study.

Deal one: buying scale instead of waiting for it

In 2021, Allica bought Allied Irish Bank's GB SME lending book. That's not a flashy move. It's literally buying an existing portfolio of business loans rather than originating them one at a time.

For a young bank still figuring out its identity, this did two things at once. It gave Allica immediate scale in commercial lending, and it handed them a proven template for exactly the kind of customer they wanted to serve going forward: established SMEs. Instead of spending years slowly building trust and track record in a regulated industry where trust can't be manufactured through marketing, they bought a working example of it.

Think of it like acquiring a mature codebase with real production traffic instead of building your MVP from zero and hoping users show up.

Deal two: filling a specific gap, not chasing raw scale

By August 2024, Allica had organically built out commercial mortgages, asset finance, and growth finance. One thing was missing: bridging finance. Rather than spend years building that expertise from scratch, they acquired Tuscan Capital, a specialist in semi commercial and full commercial bridging loans.

This is the more instructive deal of the three. It's not about buying size, it's about identifying one precise capability gap and acquiring a team that already did that one thing well. Most fintech M&A coverage focuses on splashy consumer app acquisitions, but this kind of surgical, boring acquisition is arguably the more useful pattern to actually learn from.

It's the equivalent of not building your own payments infrastructure because a team already nailed it, and just acquiring them instead of reinventing it internally.

Deal three: Kriya and the jump into a new category entirely

The biggest move came in October 2025: an all share acquisition of Kriya, the SME working capital and PayLater fintech previously known as MarketInvoice and MarketFinance. Founded in 2011, Kriya had already processed over £4 billion in SME finance across more than 300,000 transactions, with a PayLater product built on a Stripe partnership already live with retailers like Halfords.

This one's different from the first two. It wasn't filling a gap in an existing product line, it was entering an entirely new category: embedded finance. Kriya kept its own brand, and its CEO Anil Stocker stayed on, saying joining forces with Allica gave the business the platform to scale further. The stated goal attached to the deal is concrete: £1 billion in working capital finance to SMEs over the next three years, part of a broader push toward 10% share of the established SME market by 2028.

Why the sequencing matters more than any single deal

Look at the order here. First, buy raw scale. Then, fill a specific product gap. Then, acquire your way into an entirely new category. That's not opportunistic dealmaking where you grab whatever's available. It's a deliberate sequence, and it's a decent signal for where fintech M&A is heading more broadly: acquisition as a growth lever, not a fallback when organic growth stalls.

If you're building or scaling a product and treating "build everything ourselves" as the only legitimate path, this is a useful counterexample. Acquisition can be a precision tool. You can use it to buy scale, buy a missing capability, or buy your way into a new business line entirely, and each of those is a different decision with a different playbook.

Allica's three deals each did exactly one of those jobs. The £3.7 billion loan book isn't the result of one big bet. It's the result of getting that sequencing right, three separate times, for three separate reasons.