In 1985 You Could Get an Oracle Trial License. In 2014, No Policy Admin System Offered the Same.

Dan Woods came to insurance from data platforms, not from insurance itself. A classically trained pianist with a computer science and AI background, he spent years before Socotra working at Palantir, the data analytics company co-founded by Peter Thiel — whose Founders Fund later led Socotra’s seed round. What pulled him toward insurance specifically wasn’t the industry’s products; it was a specific, oddly-shaped data and infrastructure problem he found genuinely aesthetically satisfying to think about.

In Episode 60 of InsurTechTalk, Dan and I covered why he thinks of an insurance policy like a shipping container, what actually separates a true “cloud” product from software just running on a rented server, and the specific moment he realized that not a single policy administration vendor on the market was selling an actual, evaluable product.

About Dan Woods

Dan Woods is CEO and founder of Socotra, a cloud-native, open-API policy administration platform for insurance carriers and MGAs, founded in 2014. Before Socotra, he worked at Palantir, the data analytics company co-founded by Peter Thiel, whose Founders Fund led Socotra’s seed round. At the time of this recording, Socotra had raised $45 million and grown its team from 44 to roughly 88 people over the course of 2021.

The Container Ship Analogy

Dan’s framing for what insurance actually does, economically, is worth taking seriously as a mental model. He compares an insurance policy to a shipping container: containers aren’t the most space-efficient way to move goods, but their real value is standardization — they make arbitrarily different cargo stackable, containable, and predictable, so business can move efficiently without needing to individually assess every shipment’s risk. Insurance does the same thing for business operations generally: without it, every transaction carries an implicit asterisk (“this costs X, unless Y happens”) — and stacking hundreds or thousands of those unresolved asterisks across a real business becomes unmanageable. Insurance resolves that by putting a firm financial boundary around the risk, making otherwise-unpredictable operations plannable.

Extending the analogy together in the conversation, we landed on: if policies are the containers, carriers are the ships, and their underwriting appetite is their cargo capacity — meaning a core system’s job is fundamentally about helping a carrier pack, size, and manage that capacity well, rather than either underutilizing it or overloading it into tail risk.

What a Core System Actually Does, Stripped to Basics

Asked to explain policy administration at its most fundamental level, Dan broke it down plainly: it’s the system that stores the actual data representation of a policy, typically generates quotes (sometimes handled by a separate system instead), and manages renewals, cancellations, and endorsements — mid-term policy changes. That last piece gets complicated fast: if a policyholder requests a change today, and another change is quoted later that needs to take effect either before or after the first scheduled change, the system has to correctly sequence and price both, then translate everything into invoices that are correct down to the penny, correctly split across premium, fees, and any ceded reinsurance premium — all while the underlying insurance product itself may have several versions running side by side, since a policy’s terms are governed by whatever rules were in effect when it was originally underwritten, not the current rules. Multiply that complexity by fifty states, Dan noted, and you understand why so many well-intentioned, talented insurtech founders underestimate how deep the rabbit hole goes before they’ve even shipped one state.

Mainframes, “New Legacy,” and What Cloud Actually Means

Dan walked through the industry’s core system history directly: many tier-one carriers still run policies on systems that have been running continuously since the 1970s, written in COBOL on mainframes, maintained by a shrinking handful of veteran architects being paid increasingly large sums to delay retirement, since they’re often the only people who still understand how the whole system actually works. The Guidewire generation moved things onto PCs, still generally on-premises and heavily customized — what Dan called “the new legacy.”

He drew a sharp distinction on what “cloud” actually means versus how the term gets misused: installing on-premises software on a rented server in someone else’s data center is not cloud, any more than moving your own power generator to another building with an extension cord constitutes joining a real electrical grid. Genuine cloud software — his examples: LinkedIn, Dropbox, Gmail — continuously upgrades itself, exposes open APIs anyone can use, and functions as a utility you simply plug into, not a static, delivered artifact you separately maintain.

Best of Breed, Off the Shelf, and Why “Just Use Stripe” Is the Future

Dan connected this to a broader shift already visible in more tech-forward industries: the era of a single enterprise vendor building everything is ending, replaced by assembling genuinely best-of-breed, truly off-the-shelf components. His test for “off the shelf” is simple and concrete: can a new customer sign up and be fully using the product within about ten minutes, the way you can with a Dropbox or Gmail account? Socotra deliberately doesn’t build its own payment processing, for exactly this reason — an early customer, surprised that Socotra didn’t include a payment processor, got the direct answer that building one made no sense when Stripe, Square, and a dozen others already do it well and expose the APIs to prove it. In Dan’s framing, true enterprise differentiation increasingly comes from how you configure and connect these off-the-shelf components together, plus whatever genuinely custom experience layer sits on top (particularly the consumer-facing pixels), not from rebuilding commodity infrastructure yourself.

Socotra’s Marketplace: A Library, Not Just Connectors

Dan described a beta product, first outlined at ITC Vegas, called Marketplace — the ability to add integration components to a Socotra deployment roughly as easily as installing a browser extension: pick a provider, supply credentials, answer a handful of questions, and the connection exists. His broader point about why this matters more than it sounds: writing a single point-to-point integration involves far more than the connector code itself — hosting, deployment, credential security, logging, monitoring, and safely handling version upgrades without downtime. Productizing all of that infrastructure, not just the connector logic itself, is what actually collapses the effort by more than an order of magnitude, and Marketplace’s public library is a byproduct of that underlying productization, not the core value itself — customers connecting Socotra to obscure internal or proprietary systems benefit just as much from the same infrastructure, even without a pre-built connector waiting in the library.

Why Legacy Vendors Can’t Just “Publish an API”

Asked why incumbent policy administration vendors haven’t simply published open APIs the way Socotra has, Dan’s answer was pointed: it’s not secrecy or embarrassment about outdated technology — it’s that there often isn’t one single API to publish in the first place. Legacy vendors have historically built a custom version of their software (and its API surface) for each individual customer, meaning there’s no single, coherent, publishable interface underlying the product at all.

The Origin Story: Nobody Was Actually Selling a Product

This was the most striking part of the conversation. Around 2014, Dan connected with a private equity firm executing a roll-up of insurance companies, looking to standardize on modern policy administration software across its acquisitions. Evaluating the market, every single vendor turned out to be, in practice, consultants selling bespoke custom software rather than a genuine product: no public documentation, no way to evaluate the software independently, and in some cases requiring four separate sales meetings before even disclosing a price range. Dan was already prepared for outdated technology, on-premises deployment, and poor API documentation — what genuinely surprised him was that not a single policy administration system on the market in 2014 was productized enough that a prospective customer could simply request a trial license and documentation and start evaluating it, the way he’d been able to trial Oracle’s database product back in 1985.

He extended the comparison directly to public API documentation as a signal of whether a company is actually selling a product: he cited a slide he’d presented at ITC showing companies across industries — Stripe, Twilio, AWS, Google, Microsoft, even SpaceX (whose satellite APIs are genuinely public) — that publish their APIs openly, making it possible, in his example, for a skilled engineer to build a weekend project that finds nearby pizza via Google Maps, cross-references ratings on Yelp, places the order through DoorDash, and texts delivery instructions via Twilio, entirely through public APIs strung together. That level of composability, he argued, has been almost entirely absent from insurance core systems, where even a basic bindable quote has historically been the practical ceiling of what’s exposed programmatically, before even considering billing and payment processing.

“Someone’s Got to Write the Policy Admin Component”

Dan connected the market gap directly to a version of the efficient-markets joke often attributed to the Chicago School of economics: the idea that a genuine $20 bill lying on the sidewalk would already have been picked up by now, so anyone who spots one must be wrong about it being real money. His point: people assume foundational infrastructure like a genuinely productized, open policy administration system must already exist, simply because it’s easy to imagine — while conference conversation gravitates toward flashier, higher-level topics like AI and blockchain rather than the less glamorous question of how the underlying data is actually structured, stored, and exchanged. Socotra’s stated mission is specifically building that missing foundational layer for the modern, best-of-breed insurance enterprise stack.

Rethink Insurance: A Conference Built Around Not Being on Stage

Dan previewed Socotra’s own conference, Rethink Insurance, held January 27, 2022 in Palo Alto. His explicit design choice: Socotra itself would spend minimal time on stage, instead giving the platform to its own carrier and insurtech customers and partners — a mix of tier-one insurers and newer insurtechs — to present their own innovations directly, with Socotra’s only ask being a logo somewhere on a slide. The event’s broader theme extends beyond Socotra itself to the larger shift toward composable, cloud-native, open-API enterprise architecture across the industry.

Advice: Macros, Fasting, and Finally Listening to the Advice Everyone Already Gives

Asked for a closing recommendation, Dan described a genuine health overhaul during COVID: counting macros for the first time and being surprised by how mathematically predictable body composition changes turned out to be, building a home gym once his regular gym became inaccessible, and digging into the underlying chemistry of different sugar types and how they’re metabolized differently depending on molecular structure and where digestion occurs. He also took up intermittent fasting, starting — at his trainer’s suggestion — with an initial 36-hour fast he expected to be miserable and instead found genuinely manageable, since hunger, in his experience, doesn’t scale linearly with fasting duration the way people assume. His current routine: one 36-hour fast monthly, two 18-hour fasts weekly, and an occasional longer fast around the new year. His reframe of the purpose: not primarily about becoming thinner, but about genuinely appreciating food more — fasting earlier in the week specifically so a wine dinner or multi-course meal later in the week can be enjoyed fully rather than eaten out of habit.

Key Takeaways

• Dan’s container-ship analogy frames insurance’s core economic function clearly: converting otherwise unpredictable business operations into bounded, stackable, plannable risk — a genuinely useful mental model for what a policy actually does
• True “cloud” software is defined by continuous upgrades, open APIs, and utility-like reliability — not merely running previously on-premises software on a rented server elsewhere, a distinction Dan considers widely misunderstood in enterprise software generally
• The best-of-breed enterprise model (assembling genuinely off-the-shelf, API-connected components rather than one custom-built system) is already the norm in more tech-forward industries, and Socotra’s own product philosophy — not building its own payment processing, for instance — reflects a deliberate bet that insurance core systems are following the same path
• Socotra’s origin traces to a concrete, surprising discovery: as of 2014, no policy administration vendor on the market was actually selling a productized, independently evaluable product — every one required custom sales engagement just to learn pricing, let alone trial the software
• Legacy core system vendors’ inability to publish open APIs isn’t about secrecy — it’s structural, since many built a bespoke, one-off version of their software (API surface included) for each individual customer, leaving no single coherent interface to publish
• Public API documentation itself functions as a credibility signal for whether a company is a genuine product business — Dan’s comparison set (Stripe, Twilio, AWS, SpaceX) illustrates a level of composability that insurance core systems have historically lacked almost entirely
• A genuinely disciplined approach to intermittent fasting (regular 18- and 36-hour fasts) can, per Dan’s own experience, make hunger feel less linear than expected — and reframing fasting around appreciating food more, rather than pure weight management, made the habit durable for him