Insurance Quoting Can Take 30 Seconds. On the Internet, That’s the Same as a Website That Doesn’t Work.

Louw Hopley is a software engineer who’s been building things since school — apps on the App Store for pocket money as a kid, drones and electronics as an adult hobby, and eventually a full insurance core system as a company. Root Platform started from a deliberately broad question: not “how do I fix insurance” but “where’s the intersection of a genuinely complex, regulated industry (financial services) and the developers who actually have to build inside it?” That question narrowed over time specifically into insurance, and into a thesis Louw describes almost literally: build the Lego blocks insurance is missing.

Root started in Cape Town, South Africa — chosen simply because that’s where Louw’s networks, contacts, and available talent already existed — and has been running for roughly seven years, expanding into the UK market about six months before this recording.

In Episode 101 of InsurTechTalk, recorded ahead of ITC DIA Europe in Barcelona, Louw and I covered why Root treats API developer experience as seriously as Stripe does for payments, why South Africa’s insurance market taught Root the wrong lesson about how broad to build, and what genuinely separates a “core system” from the quoting tools most people mistake for one.

About Louw Hopley

Louw Hopley is CEO of Root Platform (rootplatform.com), a cloud-based, low-code core insurance platform built to let carriers and MGAs launch modern digital insurance products, particularly through embedded and white-label partner channels. Root started in Cape Town, South Africa, and expanded into the UK roughly six months before this recording. The platform spans quoting, binding, policy administration, payment collection, and claims — positioning itself as a genuine alternative or complement to incumbent core systems like Guidewire and Duck Creek.

Launching a Product in Under Two Weeks

Root’s headline capability, and the thing Louw was preparing to demo live on stage at ITC DIA Barcelona: going from zero to a functioning insurance product template in a matter of minutes, with a fully configured, branded, launch-ready product achievable in as little as two weeks — the fastest instance Root has actually shipped.

His genuinely important observation about where the bottleneck has moved: technology is no longer the constraint. If an insurer or MGA already has finalized policy wording, pricing logic, and regulatory sign-off ready, the technical build-out can happen in minutes to hours of configuration. The remaining friction — compliance, wording finalization, regulatory approval — now sits entirely on the insurer’s side of the fence, not the platform’s.

Why Slow Quoting Is a Genuinely Broken User Experience

Louw’s framing of the API problem in insurance is sharp and worth internalizing: many companies retrofit APIs onto legacy core systems never designed for real-time integration, producing quote response times that can run upward of 30 seconds — treated as normal in the industry. His comparison: imagine a social media feed that took 30 seconds to load, or a tweet that took 30 seconds to post. Nobody would tolerate that outside insurance; inside it, it’s the status quo.

The second problem he identified is more subtle: even where APIs exist, they’re often built with no real attention to developer experience — sparse documentation, unintuitive structure, no real onboarding path. His analogy: raw API endpoints without the surrounding guides, tutorials, and documentation are like wooden blocks that don’t actually snap together — technically Lego-shaped, functionally useless without a manual, which defeats the entire purpose in an industry too complex for developers to intuit correctly on their own. Root’s explicit inspiration here is Stripe’s approach to payments — treating the developer experience itself as a first-class product, not an afterthought bolted onto backend functionality.

South Africa Taught Root the Wrong Lesson About Breadth

This was a genuinely useful and counterintuitive market-structure insight. South Africa’s insurance market is comparatively broad rather than specialized — Louw’s example: where a UK insurer might be a dedicated, massive pet insurance specialist, the equivalent South African insurer more commonly sells pet insurance as a secondary or tertiary product line alongside several others, because the market simply has fewer specialists across the board.

Root built its platform to be genuinely product-agnostic (life, device, motor, and more) largely because that’s what the South African market required. When Root expanded into the UK, the team initially worried they’d built the platform “too broad” for a market where every player is narrowly, deeply focused on a single niche — but that same breadth turned out to be a real asset, since UK insurers frequently have no internal path to reach adjacent products or channels outside their specialty, something Root’s platform was already built to support.

The broader data point: South Africa carries roughly 17% gross written premium as a share of GDP — genuinely high insurance penetration — versus roughly 2% average across the rest of Africa, where insurance in most rural areas is functionally not a consumer category at all.

Why Insurance in Africa Requires Solving Payments First

Louw’s framing of why African insurance markets are structurally harder to build in than mature Western markets extends a Maslow’s-hierarchy analogy directly: foundational financial infrastructure — reliable payments and basic money movement — often doesn’t exist yet in much of the continent, which means insurtechs there frequently have to solve payments before they can meaningfully introduce credit, then loans, then investment products, and only then insurance. Building insurance products in that environment means solving several stacked infrastructure problems simultaneously rather than one.

We compared notes on the flip side of this: Africa, in many cases, leapfrogged legacy payment infrastructure entirely, going straight to mobile-based payment rails rather than passing through the card-and-check infrastructure that Western markets had to slowly modernize away from — a genuine advantage of not having entrenched legacy systems to migrate off of.

Root as a Genuine Core System, Not a Quoting Tool

I pushed Louw directly on where Root sits in the ecosystem — is it a core system in the Guidewire/Duck Creek sense, or closer to a lighter-weight product quoting tool? His answer was unambiguous: Root is a core system, comparable in category (if not vintage — he was happy to concede Guidewire and Duck Creek now qualify as “the new legacy,” purely on age) to the established incumbents.

His reasoning: launching a genuine insurance product requires far more than quoting — you need the full lifecycle: adjustments, renewals, billing instruction execution, failed payment retry logic, retention workflows, customer communications. Root’s API surface covers all of it, and many clients run Root alongside an existing Guidewire deployment specifically because launching a new product on their legacy system is prohibitively slow and expensive, while Root gets them to market fast in parallel.

The Actual Product: Bridging Carriers and Non-Insurance Brands

Root’s core commercial use case is embedded and white-label insurance, structured around three parties: the carrier or MGA (owns underwriting and product), the customer-facing brand (a retailer, telco, bank, or digital platform with existing distribution and customer relationships), and Root itself, sitting in the middle as both the platform the policy actually runs on and the facilitator of communication between two parties whose priorities are structurally in tension.

Louw’s description of that tension is the clearest explanation I’ve heard of why embedded insurance projects stall: the brand wants to ask the customer as few questions as possible to protect conversion; the insurer wants to ask more questions to price the risk accurately. Root’s role explicitly includes facilitating and coaching both sides through that negotiation — not just building the technical bridge, but managing the underlying product conversation between two parties who don’t naturally speak the same language.

Build vs. Buy vs. Rent

Asked how insurers should think about the build-versus-buy decision for core infrastructure, Louw’s framework was direct: focus your engineering effort on what genuinely differentiates you — the customer-facing app, website, or partner integration — and avoid rebuilding commodity infrastructure that dozens of vendors already do well (his specific example: nobody needs to build their own PDF policy document generator from scratch and then maintain it forever).

His deeper critique of the build-it-yourself instinct: insurance products are genuinely heterogeneous — two products that look similar on the surface often need meaningfully different underlying logic — which means insurers who build their own core tech tend to end up with idiosyncratic systems tightly coupled to their specific product, locking them into perpetual internal engineering investment just to keep the lights on, rather than spending that capacity on what actually differentiates them to customers.

Advice: Don’t Assume Two Big Clients Are the Same Client

Asked for closing advice — specifically about his own company-building journey rather than life advice broadly — Louw’s answer was refreshingly self-critical. Despite being warned repeatedly by advisors, Root made the mistake of treating two large enterprise clients as equivalently good simply because both were large and generated significant revenue — only to discover they were structurally very different customers with different decision drivers, workflows, and internal personas involved. That experience pushed Root toward much tighter focus on customers sharing the same underlying traits, goals, and organizational roles, which in turn let the team build a more focused product and materially better customer experience — insurance being too heterogeneous a category to treat “big enterprise client” as a single, interchangeable persona.

Key Takeaways

• The technical bottleneck in launching a new insurance product has genuinely shifted from engineering to compliance and wording finalization — a well-prepared insurer can go live in as little as two weeks with the right platform
• 30-second quote response times, common in legacy-retrofitted insurance APIs, represent a genuinely broken user experience by the standards of any other modern digital product category
• API quality in insurance means far more than functional endpoints — documentation, onboarding guides, and genuine developer experience determine whether an API is actually usable at all
• Market breadth versus specialization varies enormously by geography — South Africa’s broad, multi-line insurers shaped Root’s product-agnostic platform in a way that turned out to be a genuine asset entering the more niche-focused UK market
• Emerging markets frequently must solve foundational financial infrastructure (payments, basic money movement) before insurance products can meaningfully exist, layering the challenge well beyond what mature markets face
• A genuine core system spans the full policy lifecycle — quoting is only the entry point; renewals, billing, retention, and claims all need to be covered for a platform to displace or complement an incumbent like Guidewire
• Embedded insurance’s central operational challenge is reconciling structurally opposed incentives between the underwriting party (wants more data) and the distribution brand (wants minimal friction) — a negotiation the platform provider often ends up actively facilitating, not just enabling technically
• Treating all large enterprise clients as interchangeable, simply because they’re large, is a costly mistake — genuine focus on shared customer traits and workflows produces a better product than chasing revenue-scale alone