DEV Community: harry

Agentic Workflows in the Enterprise — What Omnea Gets Right About AI Agents That Aren't Just Chatbots

harry — Fri, 07 Aug 2026 07:14:12 +0000

"AI agent" has become one of those terms that means everything and nothing. Omnea, a procurement automation platform out of London, is a useful concrete example of what an agentic workflow looks like when it's solving an actual operational bottleneck rather than being bolted on as a chat interface.

The problem wasn't "we need AI," it was a broken process

Before reaching for AI as a solution, it's worth looking at the actual bottleneck: enterprise procurement reportedly takes an average of six months and involves upward of a dozen stakeholders to move a purchase from request to approval.
That delay is what pushes employees to bypass procurement entirely, creating shadow IT and untracked vendor risk. The AI here isn't solving "how do we add a chatbot," it's solving "how do we compress a multi stakeholder approval chain without losing the compliance checks that chain exists to enforce."

That distinction matters for anyone building agentic systems. An agent that just answers questions faster isn't actually removing the bottleneck. An agent that can route a request, check it against policy, flag risk, and pull in the right approver automatically is doing something structurally different, it's replacing a workflow, not accelerating a query.

What "agentic" actually requires here

For an agent to safely automate a procurement request, it needs to reliably do several things in sequence: interpret an ambiguous natural language request, check it against evolving compliance rules (which change per regulation, per vendor category, per region), route to the correct human approver when a decision genuinely needs a person, and log every decision it made and why.
That last part, the audit trail, is arguably the most underrated piece of building agents for regulated or high stakes workflows. An agent that can't explain its own decision path is a liability in any process someone might need to audit later.

The regulatory pressure is a feature of the design constraint, not an obstacle

Procurement automation exists inside a tightening regulatory environment, obligations like DORA and the EU AI Act put real constraints on how AI assisted vendor decisions have to be documented and justified.
Rather than being a compliance headache bolted on afterward, this kind of constraint is arguably what forces agentic systems to be built well: reasoning has to be traceable, decisions have to be explainable, and "the AI decided" can't be the end of the audit trail.

The takeaway for anyone building agents

The genuinely useful agentic products aren't the ones that added a conversational layer to an existing dashboard. They're the ones built by starting from an actual broken workflow, mapping every stakeholder and constraint in that workflow, and only then figuring out where an agent can safely replace a manual step without losing the guardrails the process needed in the first place.
That's a much less flashy design process than "add an AI feature," and it's exactly the discipline that's easy to skip if you're chasing the current wave of UK startup news around agentic AI rather than the underlying operational problem.

Push vs. Pull — A Developer's Field Guide to Payment Rails

harry — Tue, 04 Aug 2026 06:54:45 +0000

If you've only ever integrated card payments, there's a whole category of payment rails you're probably underusing: bank-to-bank transfers. Cards are a push model, the customer authorizes each charge in the moment. Direct Debit and open banking payments work completely differently, and picking the wrong one for your use case creates real engineering headaches down the line.

The rails, briefly

Bacs (UK) and SEPA Direct Debit (EU) are pull-based, and Bacs specifically is the rail most of the UK startup ecosystem defaults to for subscription billing. Once a customer signs a mandate, you can initiate collections on your own schedule without them re-authorizing each time.

ACH in the US works similarly but with its own quirks around same-day windows and return codes that differ meaningfully from Bacs' processing cycle.

Open banking payment initiation (PIS), running over rails like Faster Payments or SEPA Instant, flips the model. It's push-based like cards, but instead of card networks, the customer authorizes a transfer directly from their bank in real time. Settlement is near-instant, but you can't use it for unattended recurring billing the way you can Direct Debit, unless you're using variable recurring payments (VRP), which is still inconsistently supported across banks.

Why this matters for your architecture

If you're building recurring billing, the mandate lifecycle is the part people underestimate. A mandate can be active, pending, cancelled, or expired, and your system needs to handle a customer revoking it directly with their bank, not just through your app. That means webhook-driven mandate status updates aren't optional, they're core to not double-charging or silently failing to collect.

Settlement timing also changes your data model. With cards, you generally know success or failure within seconds. With Direct Debit, a payment can appear "submitted" for days before it either clears or bounces, and it can still be reversed afterward via indemnity claims. If your system treats "submitted" as "paid," you will eventually ship a bug that lets someone use a service they never actually paid for.

Picking the right rail for the job

*A rough mental model that holds up in practice:
*
Predictable recurring billing where the amount is known in advance → Direct Debit (Bacs/SEPA/ACH)
One-off payments where speed matters and instant confirmation is required → open banking PIS / Pay by Bank
Variable, irregular recurring charges → VRP where supported, otherwise a hybrid of card-on-file plus fallback

Most serious payment platforms (Stripe, GoCardless, and others) now support multiple rails behind one API, which is generally the right call unless you have a very narrow use case, since it lets you route by cost, speed, and reliability rather than betting everything on one scheme.
It's a pattern worth watching if you follow UK tech news, since more of the payment infrastructure being built out of London is converging on exactly this multi-rail approach rather than picking one scheme and locking in.

API-First Banking: Which UK Business Accounts Actually Fit a Dev Stack

harry — Sat, 01 Aug 2026 07:18:38 +0000

Most "best business bank accounts" roundups are written for accountants. This one's written for the founder who's going to be the one wiring the account into Xero, reconciling Stripe payouts, or writing a script against a banking API at 11pm. If you're a technical founder, the question isn't just "what does it cost" it's "what can I automate, and what breaks my workflow."

Here's how the five main UK digital business accounts stack up on integration depth, not just fees.

Accounting integrations: table stakes, but not equal

Account	Xero	QuickBooks	FreeAgent	Sage	API access
Starling	✅	✅	✅	❌	Limited
Tide	✅	✅	✅	✅	Limited
Mettle	❌	❌	✅ (included)	❌	❌
Monzo (Pro)	✅	✅	✅	✅	Limited
Revolut Business	✅	✅	❌	❌	✅ Full API

If your accounting stack is FreeAgent, Mettle's the interesting one FreeAgent (normally ~£150/year) comes bundled at no extra cost, so your invoicing, tax pots, and receipt scanning are already wired together out of the box. No API needed because the integration is native.

If you're the kind of founder who wants to build your own reconciliation logic, or automate payouts and payment triggers rather than relying on a dashboard, Revolut Business is the only one here with genuine API access for programmatic payment management. It's also the only account offering real multi-currency handling (25+ currencies at interbank rates on your first £1,000/month, Basic plan), which matters if your billing logic has to deal with anything beyond GBP.

Real-time feeds vs batch sync

Starling's accounting integrations run as real-time feeds into Xero, QuickBooks, and FreeAgent transactions show up in your books as they happen rather than on a nightly batch. If you're debugging a reconciliation mismatch, that's the difference between checking today's transactions and waiting until tomorrow's sync to see if a payment landed.

The account-opening flow, from a dev's perspective

Onboarding speed varies more than you'd expect for something that's mostly KYC:

Tide: account opens in under five minutes, no credit check — the fastest path if you need to start invoicing today.
Mettle: same-day.
Monzo Business: same-day.
Starling: same day to several days it runs a hard credit check as part of onboarding, which is the trade-off for being a fully licensed bank with lending available later.
Revolut: same day to several days, and as an EMI (not a full bank), automated compliance reviews can occasionally freeze an account mid-verification worth knowing before you route your only operating account through it.

What actually breaks people's workflows

The gap that catches founders out isn't the API it's invoicing being paywalled. Monzo's free Lite tier drops invoicing entirely; you need the £9/month Pro tier to get it back, alongside full accounting integrations. Tide's free tier gives you three invoices a month before per-transfer fees start applying more broadly. If invoicing is core to how you get paid, model that into "free" before you pick.

This kind of tooling breakdown gets tracked regularly as part of ongoing startup founder stories coverage worth a look if you want the fuller comparison across FSCS limits and onboarding timelines too.

Bottom line for technical founders

Building your own payment automation or dealing with multi-currency logic → Revolut, for the API access.
Already committed to FreeAgent and want zero integration work → Mettle.
Want real-time accounting sync without touching an API → Starling.
Need to invoice fast, credit check is a blocker for you → Tide.

Pick based on what you're actually going to build against, not the marketing homepage.

Integration and API details verified against provider documentation as of mid-2026; feature sets change, so confirm current capabilities before wiring anything into production.

The Company That Lowers Its Own Prices on Purpose and Just Moved Its Stock Listing to Prove the Strategy Works

harry — Fri, 31 Jul 2026 08:13:08 +0000

Most companies raise prices as they grow. Wise has spent over a decade doing the opposite — deliberately shrinking its own take rate year after year — and in May 2026 that strategy earned it something almost no other London-listed fintech has: a primary listing on Nasdaq, while keeping its original London listing running alongside it.

The pricing strategy that looks backwards until you see the numbers

Wise's core metric, its take rate — the percentage of transaction value it keeps as revenue — fell from 64 basis points in early 2025 to 51 basis points by the fourth quarter of its most recent fiscal year. On paper, that's a company charging customers less for the same service, quarter after quarter. In practice, it's the engine behind Wise's growth: cross-border volumes reached £47.4 billion in a single quarter, up 25% year-on-year, while active customers climbed past 10.9 million.

We think this is the part worth sitting with, and it's a story that deserves more attention than it's had in most UK business news coverage of fintech: most growth businesses expand by capturing more value per customer over time. Wise has built a genuinely unusual model where shrinking the price per transaction is the thing that drives more transactions, more customers, and ultimately more total revenue — a bet that only works if volume growth consistently outpaces the margin you're giving away.

Why a UK fintech pioneer just made America its primary listing

Wise listed in London in 2021 as one of the city's flagship tech IPOs. In May 2026, its primary listing moved to Nasdaq under the ticker WSE — while Wise deliberately kept a secondary listing on the London Stock Exchange rather than abandoning it. That dual structure is the detail worth paying attention to: this wasn't a clean break from London, but a calculated bet that Nasdaq's deeper liquidity and larger base of tech-fluent investors would better reward a high-growth technology company than UK markets historically have.

The financial backdrop supported the move. Wise's most recent fiscal year showed net revenue of roughly $2.5 billion, up 19% year-on-year, with the company processing around $243 billion in cross-border transfers across more than 18.9 million active customers in over 160 countries.

Turning the payment rails themselves into the product

Alongside its core consumer transfer business, Wise has been building out Wise Platform — a white-label infrastructure product that lets banks, neobanks, and other tech companies run global transfers on Wise's own rails rather than building the capability themselves. That's a meaningfully different business than the one most people associate with the brand: instead of just competing with banks on price, Wise is simultaneously selling those same banks the infrastructure to compete better themselves.

This is where the story stops being about cheap money transfers and starts looking like the fintech-as-infrastructure playbook: build the rails, prove them at consumer scale, then license them to the institutions that would otherwise be your competitors. It's a strategy that only becomes credible once you have Wise's transaction volume behind it — which is precisely why this platform push is happening now rather than five years ago, and it's the kind of pattern worth watching if you follow UK tech news for signals on where fintech infrastructure is heading next.

What the next chapter is actually testing

Wise's ambitions don't stop at payments. The company has said it's pursuing a US national banking charter, aiming to partner with thousands of American banks directly, and its leadership has framed the entire strategy around becoming what it calls "the network for the world's money" rather than simply a cheaper way to send it abroad.

What we take from Wise's trajectory is that the dual listing isn't really the headline — it's a consequence of a pricing strategy that's been compounding quietly since 2011. Give customers a shrinking price and a growing reason to trust you with more of their money, and eventually the market structure around the company has to catch up to what the underlying business has already become. Whether "network for the world's money" turns out to be an accurate description or just a good tagline is the part still being tested.

The Engineering Story Hiding Inside Fresha's $1B Valuation

harry — Thu, 30 Jul 2026 07:12:35 +0000

Most coverage of Fresha's $1 billion valuation is written for investors: free product, marketplace fee, KKR writes an $80 million cheque, done. That's the business story. It skips the part that's actually interesting if you build software for a living — what a decision like "give the core product away for free" actually costs and demands on the engineering side.

The facts, quickly: Fresha (founded 2015 as Shedul, out of the UAE, later headquartered in London) is one of the more interesting names in UK tech news this year — it gave away its scheduling, client management, and point-of-sale software to salons and spas at zero cost. It monetised through a transaction fee on consumer bookings instead. In May 2026, KKR invested $80 million, valuing the company above $1 billion. By then it was processing more than 35 million appointments a month for roughly 130,000 businesses across 120 countries, with a revenue run-rate above $140 million growing 60%+ a year — and already profitable.

The rest of this isn't sourced from Fresha's engineering team — it's the set of problems that decision necessarily creates, worth thinking through if you're building anything similar.

Free doesn't mean cheap to run

"Free" is a pricing decision, not an infrastructure discount. Every one of those 130,000 businesses still needs onboarding, support, uptime, and data storage — and none of them are paying a subscription to cover it. When your monetisation is a thin percentage of transactions rather than a flat fee per account, the cost of serving a free user has to be low enough that the transaction fee on their eventual bookings covers it. That's a completely different constraint than SaaS teams building for a $99/month tier are used to designing against. It pushes hard toward low-touch onboarding, self-serve support, and infrastructure that scales close to linearly with usage — because there's no subscription cushion absorbing the difference.

Payments become the actual core product

Once revenue comes from a cut of every booking, payments isn't a bolt-on Stripe integration anymore — it's the thing the whole business stands on. At the volume Fresha is reportedly handling, that means reconciliation across multiple currencies and countries, handling refunds and no-shows without breaking revenue attribution, and keeping payment latency low enough that it doesn't get in the way of a customer booking a haircut. Scheduling software with payments bolted on and a payments platform with scheduling bolted on are architecturally different systems, even if the UI looks the same to the salon owner.

The lending product is really a data engineering problem

Fresha Capital — the lending product built on top of transaction history — is the part of this story that's easy to describe in a pitch deck and genuinely hard to build. Underwriting a loan off a business's real transaction data instead of a bank statement sounds simple until you have to do it reliably, in near-real time, across businesses with wildly different seasonality, in dozens of countries with different regulatory rules for consumer lending. That's not a feature you ship in a sprint. It's a data pipeline, a risk model, and a compliance surface all growing at the same time as the core product.

Why this is worth caring about even outside fintech

The broader pattern applies to any vertical SaaS product considering a free-plus-transaction-fee model: the free tier is a growth lever, but it quietly shifts your hardest engineering problems from "how do we build features people will pay for" to "how do we build infrastructure cheap and reliable enough to give away, on top of a payments layer solid enough to trust with someone else's income." That second problem is the one that actually determines whether the model works.

Fresha didn't get to a $1 billion valuation because giving software away is a clever growth hack. It got there because it apparently built the boring, expensive infrastructure underneath the free product well enough that the free product could scale without breaking the business. That part rarely makes the funding headline, but it's usually the part that decided whether the company survived long enough to get one.

Business figures above are drawn from KKR and Business Wire's May 2026 investment announcement and subsequent reporting (Sifted, The Next Web, TechFundingNews, EU-Startups). The engineering analysis is inference based on the scale and model described, not confirmed detail about Fresha's actual systems.

Tags: #saas #fintech #startup #discuss

They Rebuilt a Bank Like a Startup - Here's What Actually Worked

harry — Tue, 21 Jul 2026 08:02:31 +0000

Here's a weird origin story: in 2020, Richard Davies took over as CEO of a bank whose founder had already left. No product-market fit, no real customer base, just a banking licence and £5 million out the door in loans. Basically a blank slate with a bank charter attached.

Six years later, that bank — Allica — has lent over £3.7 billion, hit three straight profitable years, and been named the UK's fastest-growing tech company by Deloitte two years running. The interesting part isn't the growth numbers though. It's how they got there, and it's the kind of detail that gets buried in most startup founder stories in favor of the funding headline.

He'd seen the same problem from three angles

Davies didn't come up as a typical bank exec. Strategy consulting first, then almost a decade at Barclays working with SMEs. In 2013 he became the founding CEO of OakNorth, another SME-focused challenger bank. Then Revolut, where he built out their banking product across Ireland, the US, Australia, and Singapore.

So by the time he got to Allica, he'd watched the same underserved-SME problem play out inside a legacy bank, a specialist challenger, and a fast-scaling consumer fintech. That's basically 20 years of user research before writing a line of product spec.

The actual unlock: running the bank like a tech company

This is the part that'll resonate with a dev audience. Davies has said The Geek Way the book about how tech companies operate directly shaped how he restructured Allica. The core idea: strip out the layers of hierarchy and approval chains banks normally run on, replace it with the speed and ownership culture of a tech company.

They didn't outsource the tech stack either. Allica built proprietary systems in-house so relationship managers could move fast, without turning the whole thing into a faceless app. That's the real product decision here not a slicker UI, but engineering speed paired with an actual human relationship, aimed at a customer segment (established SMEs) that neither fintech apps nor legacy banks have served well.

If you've ever worked somewhere that tried to "move fast" but got strangled by approval chains, this is basically the counter-example.

AI as plumbing, not a pitch deck slide

Davies has been refreshingly unglamorous about where AI shows up at Allica. Not chatbots, not a customer-facing gimmick — it's internal. Cutting consultancy spend, speeding up product development,and streamlining the lending pipeline. The boring backend stuff that actually determines how fast a bank can say "yes" to a loan.

He's tied this to a number worth remembering: UK SMEs reportedly miss out on around £9 billion in interest every year, mostly because the products and processes built for them are outdated or just don't exist. Framed that way, the AI investment isn't innovation theater; it's closing a very specific, very quantifiable inefficiency.

The growth numbers, briefly

Quick stats for context: Fast 50 winner (fastest-growing UK company) in 2023 and 2024, Sifted's fastest-growing European startup at the end of 2024, second-fastest in Europe per the FT in 2025. ~800 employees, £371.3M revenue by 2025.

Worth noting though awards are a lagging signal, not the strategy. The actual bet stayed consistent the whole time: serve established SMEs, keep humans in the loop, skip the consumer-growth playbook. The trophies are a byproduct of sticking to that, not the plan itself.

What's next

Davies has talked about international expansion, plus pushing further into spend management and cash flow forecasting—moving from "we lend you money" toward "we're your financial operating system." The October 2025 acquisition of Kriya (embedded finance, working capital tools) is an early signal of that direction.

The actual takeaway

Strip away the banking specifics and this is a pretty clean case study in rebuilding something with no clear owner, no obvious playbook, and a founder-shaped hole in the middle. The formula: pick one underserved user, commit to one cultural bet (in this case, literally borrowing tech-company operating principles), and give it years not quarters to compound.

Whether that holds up once international expansion and new product lines start pulling the team in different directions is the part still unwritten.