The Modularity Paradox: AI Cracks the Interface Between Human and Machine

Qonto scaled to 500,000 businesses with over 15,000 native integrations. Accounting tools, invoicing platforms, expense managers, CRMs. The best-of-breed dream, fully realized.

The adoption rate for those integrations after the first week: 30-40%.

Not because the tools were bad. Because nobody was flying the plane.

The Promise That Broke

The fintech industry sold small businesses a compelling story: don't settle for one monolithic platform that does everything poorly. Instead, pick the best tool for each job. Connect them with APIs and integrations, and you'll have a stack tailored to your exact needs.

I believed this story. I spent seven years building it — first at iBanFirst, then at Qonto, where I led product for the automation engine and integrations marketplace. We were the poster child of modularity.

Here's what nobody talks about at fintech conferences: modularity works beautifully for the first three tools. By tool number seven, your finance team spends more time managing the connections than doing actual finance. The data doesn't quite match between systems. Someone has to decide, every single day, which system is the source of truth.

We had built a sophisticated switchboard. But every call still needed a human operator.

The Gap Nobody Could Close

This is what I call the modularity paradox. The more tools you connect, the more intelligence you need at the interfaces — and that intelligence has historically been human.

A bookkeeper who knows that when client X sends an invoice in USD but the account is in EUR, you use the rate from the payment date, not the invoice date. An ops manager who knows that a particular Stripe webhook sometimes fires twice and you should deduplicate before syncing to the ledger. These aren't edge cases. They are the job.

I watched this pattern repeat across hundreds of SMBs at Qonto. A five-person startup would sign up, connect Stripe and Pennylane, and everything would hum. Eighteen months later, they'd be a twenty-person company with nine tools and a finance person spending Friday afternoons reconciling discrepancies.

The standard industry response was to build more integrations. Better APIs. More automation templates. We did all of it. It helped, incrementally. But the fundamental problem remained: at every interface between two systems, someone had to make a judgment call.

Think about it concretely. Three tools means three interfaces. Ten tools means forty-five. Each interface is a place where data transforms, formats shift, and someone needs to decide what happens when things don't match. The more modular your stack, the more human glue you need. That's the paradox.

What Toyota Understood That Fintech Didn't

In 1896, Sakichi Toyoda built a loom that would stop itself when a thread broke. He didn't build a loom that never broke threads — that was impossible. He didn't build a loom that required a human watching every single thread — that was unscalable. He built a loom that knew when it didn't know what to do.

Toyota called this principle jidoka: automation with a human touch. The machine runs autonomously until it encounters something outside its confidence range. Then it stops, signals for help, and waits. A single worker can oversee thirty looms instead of one.

The genius of jidoka isn't the automation. It's the boundary. Toyoda understood that the hard problem isn't making machines that work — it's making machines that know when they don't work. That distinction turns out to be everything.

This isn't a metaphor. It's an engineering principle, and it maps directly to what's broken in modular software.

AI as the Missing Intelligence Layer

This is precisely what large language models change. Not by replacing the modules — your accounting software and your invoicing tool are fine. They do their specific jobs well. What AI changes is the interface between them.

For the first time, we can build software that operates on a confidence spectrum rather than binary logic. An AI agent can look at an incoming transaction, match it against outstanding invoices, and say: "I'm 92% confident this €4,350 payment matches invoice #1847. Auto-reconciled." Or: "I'm 63% confident — flagging for review." Or: "I'm 30% confident. Parking it."

That confidence spectrum is jidoka applied to software. The machine runs until it hits the boundary of its competence, then it calls for help. One finance person can oversee a hundred reconciliations instead of manually processing each one.

This isn't about replacing human judgment. It's about focusing it. The bookkeeper who used to spend four hours reconciling transactions now spends thirty minutes reviewing the twelve that the system flagged — and those twelve are the ones that actually need a human brain.

From Best-of-Breed Stack to Best-of-Breed Orchestration

The modularity paradox doesn't get solved by fewer tools or better tools. It gets solved by adding an intelligence layer that sits between all of them — understanding context, making judgment calls within its confidence range, and escalating everything else.

The old pitch was: "Pick the best tool for each job and connect them." The new pitch is: "Pick the best tool for each job and let an intelligent layer orchestrate them."

The difference sounds subtle. It isn't. In the old model, the human is the glue. In the new model, AI carries the context. The human steps in for the exceptions, the genuinely ambiguous cases, the decisions that require business judgment rather than pattern matching.

The shift isn't from manual to automated. It's from "human as glue" to "human as supervisor."

The Honest Version

I want to be clear about what this is and isn't. AI doesn't make modular software magically work. It doesn't eliminate the need for good APIs, clean data models, or well-designed integrations. You still need solid plumbing.

What AI does is make the plumbing usable without requiring a human standing over every pipe fitting. It raises the ceiling on how many tools a small team can effectively operate.

And it's not perfect. The confidence thresholds have to be calibrated carefully. Set them too low and the system auto-processes things it shouldn't. Set them too high and you've just built an expensive notification system. Getting this right is an engineering problem, not a marketing problem.

I've seen what happens when you get it wrong. Early in my career, I watched a bank deploy an automation that auto-categorized transactions with zero human oversight. It worked for months — until it misrouted a series of payments that cascaded into a reconciliation nightmare. The lesson wasn't that automation is dangerous. The lesson was that automation without confidence awareness is dangerous.

After seven years of building the best connectors I could, I've come to believe the connector was never the bottleneck. The intelligence at the connection point was. That's what we're building at Well — not another module, not another integration, but the layer that finally makes modularity work the way it was always supposed to.

The Toyota loom didn't eliminate broken threads. It made broken threads manageable. That's the shift.

— Maxime Champoux, co-founder and CEO of Well