Policy Administration Is a Data Model Problem That the Industry Has Been Treating as a Workflow Problem

Dan Woods came to insurance from enterprise software, not the other way around, and that inversion explains most of what makes Socotra different.

When he looked at the state of the art in policy administration around 2013 and 2014, his reaction was disbelief. His reference points were Salesforce, Snowflake, Palantir, AWS, and Twilio — and by those standards, insurance core systems were not close. So when Socotra started, the company deliberately did not ask how to build a modern version of the incumbent policy administration systems. It asked what one of those Silicon Valley enterprise companies would build if it happened to do policy administration.

His line on cloud claims in this category is worth repeating: installing legacy software on AWS is not cloud, it is server rental.

Eleven years in, Socotra has roughly 50 clients across about a dozen countries, spanning every continent except Antarctica.

In Episode 136 of InsurTechTalk, Dan and I covered why the data model matters more than the workflows, the 50-state problem that wrecks traditional systems, what a company learns from full remote work, and why he thinks AI in software is heading the same way graphical interfaces did.

About Dan Woods

Dan Woods is the CEO of Socotra, a modern cloud-native core insurance platform covering policy administration and billing, serving around 50 clients across roughly a dozen countries. His background is in enterprise software rather than insurance. Socotra has been in business about 11 years, went fully remote during lockdown and stayed that way, and maintains a physical office in Silicon Valley while Dan works from Austin.

The Gong Tradition

Before insurance, a note on culture, because Dan’s version of a standard sales ritual says something about how he runs the company.

Socotra rings a gong at its biweekly all-hands when a deal closes — three of them, in fact, sized by deal value: one for six-figure deals, a larger one for seven figures, and a third bought specially for the company’s first eight-figure deal.

The twist: the gong is rung by the newest employee present, not the sales rep who closed it. Dan’s reasoning is that so many people contribute to winning a deal and making a customer successful that singling out one person is arbitrary and unappreciative of the rest. The newest hire is chosen precisely because they are the person most likely to have had nothing whatsoever to do with the sale.

He extended the point into a critique of both industries he straddles. Silicon Valley tends to worship the engineer and assume great products sell themselves — they do not, particularly in a relationship-driven industry with large contracts. Insurance traditionally swings the opposite way, treating sales as central and engineering as an afterthought, which he ties directly to the historically poor quality of software in the industry.

What Policy Administration Actually Is

The central argument of the conversation, and the one that reframes the category:

• Conventional thinking treats policy administration as a workflow problem — start from underwriting, renewals, cancellations, policy changes, and reporting, then work backwards to support each workflow
• Dan’s view is that this is exactly why it has been done badly. Policy administration is the representation of the policy, the way Salesforce’s enduring value is its representation of the customer
• Salesforce’s interfaces, as he points out, are not what people praise about it — its data model is. It became the hub other systems attach to
• Get the data model right and the workflows attach to it: claims systems, rating at underwriting, rating for a policy change or renewal

The nuance sits in the workflows that are easy to underestimate: policies lapsing on non-payment, over- and under-payment handling, single invoices spanning charges across multiple policies. And versioning — a policy sold in June and amended in September usually has to be endorsed against June pricing, not September’s, so historical rates must stay attached to the policy.

The 50-State Problem

The structural challenge Socotra spent serious engineering effort on, and the clearest illustration of why insurance software is hard.

US insurance is regulated state by state, so selling one product nationally means maintaining up to 50 slightly different regulatory variants. The same shape appears internationally across EU member states, with currency differences layered on top. And it is not only geography — distribution channels often require their own variants with slightly different questions.

Traditional systems force one of three bad options:

1. Build 100 separate products — then maintain 100 separate products, and make every global change 100 times
2. Build one product with rule sprawl — if sold through this agency add this question, if sold in Missouri or Belgium add that one. Unmaintainable, and a change intended for one Belgian distribution channel can break every product across Europe
3. Hard-code inheritance — genuine product inheritance, but expressed in Java or similar. With no separation between product configuration and code, the deployment is instantly legacy and painful to upgrade

Socotra’s approach is product inheritance implemented as 100% configuration. Inheritance trees can go as deep as needed — one property product with a dozen state variants sharing similar regulatory treatment, then further layers below. A change across all products happens in one place; a change to one product happens in one place. And because none of it is code, weekly platform upgrades continue uninterrupted regardless of how complex the hierarchy gets.

When You Do and Don’t Need This

Dan was refreshingly honest about who should not buy his product.

• Early MGAs with genuinely simple needs often start on a spreadsheet, and he respects that — they are proving a business idea has legitimacy, not building for scale
• The same logic applies to any enterprise software: if your needs are simple enough, you do not need Oracle or Salesforce either
• The transition point is once the product has proven people want to buy it, and the goal becomes scaling to 10 million, 100 million, or a billion in premium
• He also rejected “easy to deploy” as a feature on its own: fine, but what does it do once deployed?

The Salesforce-as-Policy-Admin Story

Dan’s favorite aha moment came from his earliest research, around 2013 or 2014, when he found a very small insurer running policy administration on Salesforce itself — not a third-party product built on the platform, but raw Salesforce with everyone silently agreeing that “account” meant policy and “lead” meant application.

He found it both fascinating and a little sad: the company could not afford real policy administration software but could afford a Salesforce license and probably had someone who knew it. His read is that some enterprising semi-technical person built a working demo over a weekend and it stuck.

The lesson he drew is about what engineers actually value most in a tool, and it is not a feature:

Understandability. Engineers look at tools, work out what they can do with them, and build things — bugs they can work around if they know where they are, missing features they can add. What they need is to understand what the thing is, what it is good for, and where its limits are.

Here was a case where completely the wrong tool won because it was comprehensible.

Remote Work: A Skeptic Converted

Dan was the last member of the executive team to accept going fully remote, and he was candid about how wrong his predictions were.

Had someone told him on January 1st, 2020 that the company would be forced remote for six months, he would have put the odds of the company surviving at roughly even. He expected productivity collapse, an inability to hire for important roles sight-unseen, mental health problems among extroverts, and people distracted by the game console in the same room.

None of it happened. His department heads eventually had to tell him it was working.

What he emphasizes now:

• Recruiting and retention are dramatically better — Socotra can hire people who want to stay in their hometowns rather than uproot families, which is increasingly valuable as other companies mandate return to office
• Roughly 70–80% of employees are in the US, spread across the country
• Remote is not a cost saving. Money not spent on office space goes to travel, and travel is expensive. The old compensation arbitrage between coastal and inland hiring has largely closed — those candidates now compete for remote roles and are compensated accordingly
• He genuinely misses the office: lunches, small conversations, the informal contact that builds empathy and defuses misunderstandings

AI Will Be Infused, Not Added

Asked what AI means for policy administration, Dan reached for an analogy from the early 1990s.

Graphical user interfaces were once a distinct, remarkable thing — a GUI was an add-on for a few use cases. Nobody says “GUI” anymore; it is just an interface. His prediction is that AI follows exactly that arc: today it is bolted-on point solutions, and the destination is software that is AI-infused rather than AI-added. His design instinct is to skip ahead to that state rather than treating AI the way someone in 1994 treated adding a GUI.

Concretely, within policy administration:

• Draft an initial underwriting summary or a first-pass recommendation, especially on complex commercial risks
• Prioritize a submission queue — which one to work now for fastest turnaround, which he notes is valuable on its own
• Point to areas needing more research, or surface the five most similar policies underwritten in the past year as precedent

Socotra is also using AI on its own delivery side. In a recent internal hackathon, seven two-person teams — a deployment strategist and a solutions engineer each — were each given an unfamiliar product mandate and one hour. All seven demonstrated underwriting, viewing, and basic workflows on their assigned product. The most advanced team also had basic rating and document generation working within the hour.

Key Takeaways

• Policy administration should be built around the representation of the policy, with workflows attached to it — not assembled backwards from a list of workflows
• Product versioning is not optional: an endorsement usually has to price against the rates in force when the policy was sold
• The 50-state problem forces traditional systems into duplication, rule sprawl, or hard-coded inheritance; configuration-based product inheritance avoids all three and keeps upgrades clean
• Spreadsheets are a legitimate starting point for an early MGA — the question is recognizing when proving the idea gives way to scaling it
• Engineers’ most valued property in a tool is understandability, which sometimes beats correctness of fit entirely
• Remote work delivered recruiting and retention gains but is not a cost saving; the office budget shifts to travel
• AI in insurance software is heading toward being infused throughout the interface, the way graphical interfaces stopped being a feature and became simply how software works