We Open Sourced a Brokerage Platform

BrokerDev is live. We just open sourced the core of what we've been building, an API-first platform for insurance brokerages. You can find it on GitHub today.

This post is about why we built it, what it does, and where we're headed.

Why This Exists

If you've worked in the insurance brokerage space, you know the tooling landscape. Most brokerages run on legacy Broker Management Systems that were built decades ago. They work, and that longevity means they solve real problems, but they weren't designed for the way we build software today.

We keep hearing from brokers who are trying to do basic things - pull data into a report, automate a renewal workflow, connect their BMS to the tools their team actually uses. Forget AI for a moment, we're talking about the fundamentals. And they're getting stuck. Not because the problems are hard, but because the integrations don't exist, the support isn't there, and every request turns into another sales call and upsell.

The frustrating part is that it's getting worse, not better. These systems are becoming more closed, not more open. At a time when every other industry is moving toward APIs and interoperability, insurance tech is tightening it's grip.

I've spent enough time bridging legacy systems to know that the answer isn't ripping and replacing what works. The answer is building clean layers on top. That's what BrokerDev is.

What We're Building

BrokerDev is an open platform that gives brokerages control over their own data and workflows. We're not building another BMS - we're extending the ones you already have. The goal is a modern layer that connects your existing systems to the tools you actually want to use.

There are no hidden APIs. No internal-only endpoints that the we use but you can't touch. Every capability the platform has is exposed through the same APIs available to you. If the system can do it, so can you.

That means:

• Your data is accessible on your terms - Query your book of business through clean APIs instead of waiting on us to create exports.
• AI that actually works with your data - We implement the Model Context Protocol (MCP), Anthropic's open standard for connecting AI assistants to data sources. That means you can point Claude, ChatGPT, or any MCP-compatible agent at your brokerage data and query it with natural language. No CSV exports, no custom integrations, no middleware. Just your data, accessible to any AI tool you choose.
• Build what your brokerage needs - Custom workflows, integrations with the tools your team already uses, and features you don't have to wait on a vendor to prioritize
• Swap what doesn't work - Not happy with how we've implmented something? You can swap every component with your own custom implmentation.

The platform is modular by design. Pick the pieces that solve your problems, ignore the ones that don't.

Where We Are Today

Let's be honest about the state of things. This is early. The repo is public, the core architecture is solid, and the foundational components are in place. But we're not pretending it's production-ready for every use case.

What this means for your brokerage

Today, the platform can:

• You own your data story - Nothing is ever deleted. Every version of every record is stored forever. Need to know what a policy looked like before someone changed it? Need to prove compliance during an audit? It's all there, always.
• Your team gets answers without filing tickets - Ask a question about your business in ChatGPT or Claude and get a real answer from your real data. "What policies are up for renewal next month?" "How did our retention look last quarter?" Your team shouldn't need to wait on IT or learn new software to answer basic business questions.
• Your data is secure and role-based - Not everyone in your brokerage needs access to everything. Producers see their book. Principals and managers see the full picture. CSRs see what's relevant to their clients. You control who sees what and who can change what, down to the role level.

But the foundation is just the starting point. Where this gets interesting is what it enables.

Most brokerages run multiple systems that don't talk to each other. Your BMS holds policies, financials, and client data. Your CRM tracks sales pipeline. Your email has client communications. Your spreadsheets have the reports your team actually relies on. Every day, someone is manually copying data between these systems because there's no way to connect them.

BrokerDev is the central layer that lets these systems coordinate. Report across all your tools from one place. Automate the data entry that's currently eating hours of your team's week. When a policy renews in your BMS, your CRM knows about it without someone keying it in twice. When a client emails about a claim, the relevant policy data is already there.

The goal isn't to replace the tools you're using. It's to make them work together intelligently so your team can stop being the glue between systems and start doing actual brokerage work.

It's early, but the bones are solid. We're building on top of this foundation every week.

For the nerds

We've leaned hard on Clojure for this project. It's a functional language that runs on the JVM, which means we get access to the entire Java ecosystem while writing code that's fundamentally data-oriented. In Clojure, everything is data - your configuration, your schemas, your business logic, even your queries. That matters for a platform like this because insurance is a data problem. Policies, claims, customers, renewals - it's all structured data flowing through business rules. Clojure lets us model that directly without the ceremony and abstraction layers you'd fight in more traditional languages.

It also helps that Clojure is immutable by default, has excellent concurrency primitives, and produces systems that tend to be small, stable, and easy to reason about. A small team can move fast without tripping over itself.

On top of Clojure, we're using the Polylith architecture. If you're not familiar with Polylith, the short version is that it lets you build systems from composable components that share well-defined interfaces. All the pieces (auth, data access, business logic) are their own components that can be developed, tested, and swapped independently. It's the reason we can promise that modularity above and actually deliver on it.

Here's what's in place today:

• Polylith component workspace - Clean boundaries between every domain. Auth doesn't know about your data layer. Your data layer doesn't know about your business logic. Components talk through interfaces, not implementation details.
• Authentication - Two implementations out of the box: local auth with encrypted passwords for or small locally hosted implmentations, and OAuth via Entra ID for enterprise environments. Same interface, different backends. Need SAML or Okta? Write a component, plug it in.
• CQRS command/query separation - Reads and writes go through distinct paths. Commands handle mutations with validation and side effects. Queries are pure data retrieval. This keeps things predictable as the platform grows and makes it straightforward to add audit logging, event sourcing, or async processing later.
• Datomic data layer - We chose Datomic for its immutable, append-only model. Every change is recorded, nothing is overwritten, and you can query the state of your data at any point in time. Schema is extensible - add new attributes to entities without migrations or downtime. For an industry that cares about audit trails and historical accuracy, this matters.
• Nix for reproducible builds - Clone the repo, run nix develop, and you have every dependency pinned and ready. No "works on my machine" debugging, no version conflicts, no onboarding doc that's already out of date. New contributors get the exact same environment as production in one command.

What's coming:

• Events and message queues by default - Every meaningful action in the platform will emit events. Want to trigger a workflow when a policy renews? Subscribe to the event. Want to sync data to an external system? Listen to the queue. We're wiring this in as a first-class concern, not bolting it on later.
• BMS connectors - We've done the proof-of-concept work with PowerBroker and Epic, and the data provider pattern is ready for more backends. If you have access to your data, cough, we want to help build your connector.
• Richer domain models - Deeper policy, claims, and customer data models that reflect how brokerages actually work, not just what the BMS exposes.
• SQL reads for reporting - Datomic is powerful, but we know your team isn't going to learn Datalog to pull a report. Datomic supports a SQL analytics layer via Presto that lets you query your data with standard SQL and connect directly to tools like Metabase, Tableau, or anything that speaks JDBC. We plan to make this easy out of the box - your analysts and operations team should be able to run reports with the tools they already know, no developer required.

Open by Default

Insurance technology has been a walled garden for too long. Vendors lock you in, integrations are proprietary, and the cost of switching is astronomical and risky. We think brokerages deserve better tooling, and we think the best way to build it is in the open.

Open source

The core platform is free to use, self-host, and modify. Brokerages can inspect and deploy the code themselves. Developers can contribute connectors for the systems they know. The whole industry benefits from shared solutions to shared problems.

Building in public

We're not just publishing code and calling it open source. Our roadmap is public. Our priorities and trade-offs are visible. You can see what we're working on, what's next, and why we made the decisions we made.

Direct access

We're spinning up a Zulip community where anyone can join and talk directly with us. Ask questions, suggest features, tell us we're wrong about something. No support tickets, no account managers, no waiting for a quarterly product update to find out what's happening.

Sustainable business

Our business is built on top of the open platform - hosted solutions, custom enterprise integrations, and support for brokerages that want the platform without managing the infrastructure. Revenue funds development, not investor pressure or data monetization. The incentives stay aligned: we build a better platform, you get better tools.

Get Involved

If you're a brokerage principal looking for better tooling, or a developer working in insurance tech, we'd love to hear from you. Check out the repo.

We'll be posting here regularly - technical deep-dives on the architecture, updates on new components, and perspectives on where AI and insurance intersect. If that sounds interesting, stick around.