There’s a scene in Kitchen Confidential where Bourdain describes watching a French chef execute a perfect omelette. Not some overwrought, truffle-shaved, edible-flower-garnished spectacle, but just eggs, butter, and a pan. The technique was so clean, so deliberately simple, that it revealed something profound about the craft: mastery isn’t about adding complexity. It’s about knowing exactly what to build and having the restraint to build only that, so someone else can make it their own.
It’s kind of like AIM, in a way.
The Guy Who Actually Understood the Kitchen
In 1996, Eric Winch built software for MGAs that actually worked like an MGA works.
I know. Hold your applause.
But you have to understand the landscape. In the mid-90s, if you were a Managing General Agent or wholesale broker trying to run your operation on software, your options were systems built for retail insurance agents. The workflow was wrong, the throughput was wrong, and the assumptions baked into every screen were someone else’s assumptions.
Eric had been the IT director for a Texas-based MGA, so he’d lived in that kitchen. He founded Custom Insurance Solutions and built the Agency Information Manager (AIM) from the ground up, exclusively for the MGA and wholesale market. One of the first systems ever built that way. As Rough Notes Magazine profiled in 2005, the system “mirrors the way that submissions flow into an MGA or wholesaler, and then are processed.”
That sentence sounds unremarkable until you realize how rare it is. Most enterprise software mirrors how the vendor thinks the business should work. AIM mirrored how the business actually works. That’s the difference between a recipe and a kitchen.
The SQL Stored Procedure Revelation
My younger self had his first real “oh” moment about platform design in the AIM codebase.
If I told you that much of AIM’s business logic lived in SQL stored procedures, your immediate reaction as a modern developer might be somewhere between a wince and an involuntary shudder. Stored procedures? In 2026? What’s next, are we going to talk about the virtues of COBOL?
That logic lived in stored procedures by design. Whatever the original motivations, the result was something most software architects still haven’t figured out: a system that respected the fact that every MGA does things differently.
That’s the dirty secret of insurance technology. There is no “standard” MGA workflow. Agency A processes surplus lines submissions through a three-stage review with committee sign-off. Agency B has senior underwriters who can bind on the spot but need a different approval chain for anything over $5M. Agency C has a hybrid model where some programs are delegated authority and others require carrier approval, and the workflows for each are completely different. Same office, same floor, sometimes adjacent desks.
The effect was that AIM became customizable at a level most vendor software never allows. An agency’s IT person (or their consultant, or even a sharp operations manager who knew some SQL) could modify how the system behaved for their specific business rules. No vendor ticket. No six-month feature request cycle. No “we’ll add it to the roadmap.”
You want to validate that a field was filled out correctly and meets your custom compliance rules? Modify the validation stored procedure. Need to enforce disabling DBI invoicing? Write a trigger on the table. Want to build your own distributed clearance system? Modify the insured search view to union in other tables. These weren’t theoretical customizations. This is the stuff we actually did.
To be clear, this is a blog about building in public, not a hagiography. AIM wasn’t infinitely customizable. Not everything lived in stored procedures. Some logic was baked into the application layer, compiled into the Delphi executable, and completely untouchable. You’d hit a wall, and on the other side of that wall was behavior you couldn’t change without a vendor enhancement request and a prayer.
When that happened (and it happened plenty), we built around it. External user interfaces that sat alongside AIM, pulling from the same database but giving us the workflows and screens we needed. Custom reporting tools that went beyond what Crystal Reports could handle. Satellite applications that filled the gaps the core product couldn’t.
This is the eternal tension of working with vendor software when you don’t have access to the source code. You’re always negotiating with the boundaries of someone else’s architecture. What can we customize? We customize the hell out of it. What can’t we? We build something external. What’s in between? That’s where the creative problem-solving lives, and where most of the cursing happens.
With all that said, AIM had one more trick up its sleeve: the custom menu extension. It let you build a DLL that plugged directly into the executable. The entry and exit points were limited, but what you could do with it was launch websites and custom interfaces right inside AIM. We used that to build custom clearance screens, data entry forms, and a marketing tool that let us send templated emails for market submissions, all running within AIM’s shell. That kind of extensibility is what I’m AIMing for with Plcy.io. Pun very much intended.
Right-Click, Show SQL Query
My favorite AIM feature was the “Show SQL Query” option.
Every table in AIM had a right-click context menu option: Show SQL Query. Click it, and you’d see the exact SQL query that populated that view. The underlying SELECT statement, the JOINs, the WHERE clauses. All of it, right there.
That feature communicates something important: this is your data. This is your system. We’re not hiding anything from you. It says: we trust you to understand what’s happening under the hood, and we’re going to make it easy for you to look.
For reporting, it was invaluable. You want to build a custom Crystal Report? You don’t have to guess at the table structure or reverse-engineer the schema from the UI. Right-click, Show SQL Query, and you’ve got your starting point. You can see exactly which tables hold the data you need, how they relate to each other, and what the application is already doing with them.
For customization, it was a roadmap. Want to understand why a particular calculation works the way it does? Show SQL Query on the results table and trace the logic back through the stored procedures. It turned a black box into a glass box.
When Westrope adopted AIM back in 2004, we were coming off a product called OMNI that stored data in flat files. Before AIM, I knew nothing about SQL. Not a thing. But that “Show SQL Query” button was like leaving a door unlocked for a curious kid. I walked right through it and never came back.
I learned everything I could. Stored procedures, triggers, views. I got rather good at it. Then I got into the scary stuff nobody uses, like Service Broker and CLR integration. AIM didn’t just change how we ran the agency. It started me on the development journey. I needed to build around it, extend it, fill the gaps. And to do that, I had to learn to code. The platform didn’t just tolerate that impulse. It rewarded it.
As an aside: when I found out AIM was written in Delphi, I taught myself Object Pascal. That’s the kind of thing AIM did for me. It made me want to understand how it worked, which made me want to build things myself.
That transparency, that willingness to show you the guts of the system, shaped how I think about software design to this day.
The Platform vs. The Product
It took me years to fully articulate this, but AIM wasn’t a product. It was a platform.
A product says: here’s what we built, here’s how it works, please arrange your business to fit our assumptions. A platform says: here’s a foundation, here are the extension points, now build what your business needs.
The stored procedures were extension points. The Show SQL Query feature was documentation. The open architecture let agencies build their own portals and bridges. Jimcor Agencies built an entire online portal called Oasis that connected directly to AIM’s architecture, eliminating manual data entry for their retail agents. That was the platform at work.
And it worked. Agencies built their businesses around AIM. Not just “used AIM,” but built around it. Their workflows, their reporting, their integrations, their competitive advantages all grew out of what AIM made possible. Vertafore eventually acquired Custom Insurance Solutions in 2008, which tells you something about the value Eric built.
AIM is still widely used today. Right now. In 2026. It remains the platform of choice for wholesale brokers and MGAs across the country. Thirty-year-old software, originally built in Delphi, running billion-dollar companies.
For the uninitiated: Delphi was a rapid application development tool from Borland. Think Visual Basic’s cooler, more capable cousin that compiled to native code and could actually handle serious database work. It was the tool of choice for building Windows desktop applications in the mid-to-late 90s. Fun fact: Delphi’s chief architect was Anders Hejlsberg, who Microsoft poached in 1996. He went on to create C#, and later TypeScript. So if you’re writing C# or TypeScript today, you’re using languages that exist because of the guy who built Delphi. Borland itself barely survived the 2000s. Delphi is technically still maintained by Embarcadero, but good luck finding anyone outside of Eastern Europe who knows it. Most Delphi applications have long since been rewritten, retired, or mercifully put out of their misery.
Let that sink in for a second. In an industry where most software barely survives a single procurement cycle before the next shiny vendor comes along, a desktop application from the Clinton administration is still the backbone of major wholesale operations. Not because these companies can’t afford to switch (they’re running billions through these systems), but because AIM does what they need, the way they need it done, and they’ve built their businesses around it so deeply that replacing it would be like renovating the foundation of a skyscraper while people are still working on the 40th floor.
That’s not inertia. That’s what happens when you build a platform instead of a product. When you give people the tools to make the system theirs, they will, and then they’ll never leave, because leaving means abandoning everything they built.
Make no mistake, AIM isn’t perfect. It has its flaws. But nobody else has captured that magic formula. Others have tried. Insurity’s ConceptOne is probably the closest competitor and it’s making a real push for market share these days. The funny thing is, ConceptOne actually started the same year as AIM. Epic-Premier was founded in 1996, building for the same MGA and wholesale market. But where AIM felt like it was built by someone who ran an MGA, ConceptOne always felt more generic and opinionated. It worked great for binding authority business, the forms and workflow features were solid, but the accounting system was rough around the edges. And the original database was Sybase SQL Anywhere, which is essentially Microsoft’s T-SQL cousin that nobody has heard of… or uses. They didn’t even add SQL Server support until 2013. That’s 17 years on a database platform with almost no developer community to speak of.
ConceptOne has made real strides in recent years, and Insurity (who acquired Epic-Premier in 2020) is investing heavily. They have APIs and web services, though you have to license them separately. But the developer experience still isn’t there. Their web services are built on some sort of XML-RPC based system, and I can’t stand XML. I realize it’s very much alive and well in the insurance space. I blame the marketing around the ACORD XML standards for that, an ambitious but poorly executed attempt to standardize the insurance data model into a spec you had to pay for to even use. The ambiguity, the verbosity. JSON is just better for data exchange. Posting a massive XML payload to reconcile a few-thousand-line tax payable recon set is practically begging for a timeout.
And the database layer is its own adventure. ConceptOne has this tangled mess of triggers that run preventative validations on everything. You can’t just update a record. You have to set specific variables and run site functions to bypass the checks first. It’s the opposite of AIM’s “here’s the data, do what you need” philosophy. AIM trusted you. ConceptOne fights you every step of the way.
Vertafore, for their part, hasn’t been standing still with AIM either. They’ve been building Java-based web services that sit on top of the AIM database, and they acquired the Surefyre no-code platform to let agencies build user interfaces against those services. The problem is that the actual AIM application doesn’t use any of it. The web services and the Delphi client are two separate worlds that happen to share a database. Surefyre is bolted on alongside, not integrated into. It’s the same pattern we used to do as AIM customers: build around the parts you can’t change. Except now the vendor is doing it too.
I think platforms should eat their own dogfood. When your modern API layer is a sidecar that your own application doesn’t use, gaps don’t get found, edge cases don’t surface, and the integration stays shallow. There is a better way.
Enter Plcy.io (Thirty Years Later)
I’ve been in this industry for 27 years now, and the fundamental problem AIM addressed in 1996 hasn’t changed. If anything, it’s gotten worse. The technology has evolved. We’ve got APIs and microservices and cloud infrastructure that would’ve seemed like science fiction in the Novell NetWare days. But the core tension is identical:
Every MGA does things differently, and most software forces them to do things the same way.
That’s what Plcy.io is about. That’s the mission statement, the thesis, the hill I will die on.
The story diverges from AIM here, because the world has changed. In 1996, “customizable” meant SQL stored procedures and Crystal Reports. In 2026, “customizable” means something much bigger.
Plcy.io exposes full REST and GraphQL API access to every module and workflow. Submissions? API. Quoting? API. Policy issuance, endorsements, cancellations, reinstatements? API, API, API, API. Commission calculations, premium accounting, regulatory filings, document generation? All of it. If the platform does it, there’s an endpoint for it, and there’s a GraphQL query that lets you shape the response exactly how you need it.
This is the spiritual successor to AIM’s stored procedures, translated into modern architecture. Instead of modifying SQL to change business logic, you compose API calls. Instead of right-clicking “Show SQL Query” to understand the data model, you browse the OpenAPI spec or query the GraphQL schema with introspection.
Same philosophy. Better equipment.
Use What You Want, Ignore What You Don’t
Something drives me absolutely crazy about enterprise software: the all-or-nothing problem.
You know the pitch. Every vendor gives it. “Our platform handles everything from quote to claim!” Great. But what if I already have a claims system I like? What if my document management is handled by a system my team has spent three years customizing and they’ll riot if I replace it? What if I need your policy admin module but your accounting module makes my CFO break out in hives?
With most platforms, tough luck. You take the whole stack or you take nothing. Doesn’t matter that half the modules conflict with systems your team has spent years tuning.
Plcy.io doesn’t work that way.
Want our submission workflow but your own rating engine? Great. Hit the submission API, do your rating however you want, push the results back. Want our policy admin but you’re deeply committed to your existing accounting system? Perfect. We’ll fire webhooks on every financial event, you sync them to wherever you please. Want to build an entirely custom front-end because your underwriters have very specific opinions about how their workspace should look? Here’s the API documentation, go nuts.
The financial webhooks deserve a quick aside, because “fire webhooks” undersells what’s actually happening. When money is involved (premium transactions, commission calculations, regulatory filings), you can’t just send an event and hope the other system caught it. That’s how you end up with a policy bound in one system and an invoice missing in another. We use the Saga pattern for these cross-service workflows. A saga is a sequence of steps where each step has a corresponding compensating action. If step three fails, steps two and one roll back in reverse order. The whole chain either completes successfully or unwinds cleanly, every time. In practice: we issue a premium transaction, the webhook confirms your accounting system received it, and if the confirmation doesn’t come back (or comes back with an error), the saga triggers compensating actions to reverse what was already committed. No half-finished financial state. No orphaned records. In insurance, where a single policy can touch premium accounting, surplus lines taxes, broker commissions, and carrier settlements simultaneously, “it mostly works” is not an acceptable answer.
This isn’t just a technical decision. It’s a philosophical one: your business is unique, and your software should accommodate that uniqueness, not erase it.
The difference from AIM is scope, and the walls. AIM gave you stored procedures and a transparent database, but you’d eventually hit that compiled application boundary and have to build around it. Plcy.io is designed so you never hit that wall in the first place. Full API surface, event-driven webhooks, GraphQL for flexible querying, and an extension framework that lets you plug in your own modules alongside ours. The same APIs that power our web UI power yours, whether you’re integrating with Salesforce, streaming data to a warehouse, or building a mobile app for field underwriters.
Before someone reads “fully extensible” and hears “security nightmare”: no. This isn’t a free-for-all. Plcy.io ships with proper RBAC controls from day one. Every API call is authenticated, authorized, and scoped to the caller’s permissions. Every mutation is audit-logged: who changed what, when, and through which endpoint. The goal is to give you the keys to the kingdom without letting anyone accidentally burn it down.
AIM’s stored procedures were powerful, but they were also a bit of the Wild West. If you had database access, you had database access. We’re building something more extensible, not less, but with the guardrails that a modern platform demands.
The Developer-Friendly Imperative
One more thing AIM got right that the industry still mostly gets wrong: developer experience matters.
AIM’s “Show SQL Query” feature wasn’t just convenient. It was a statement about who the system was for. It said: developers and technical people are first-class citizens here. We’re going to make your job easier, not harder. We’re going to illuminate, not obfuscate.
Plcy.io takes that same ethic and cranks it to eleven. Our API documentation isn’t an afterthought bolted on after the “real” product is done. It’s generated from the source code, validated against the actual endpoints, and if the docs say something works a certain way, it works that way or the build fails. We have OpenAPI specs, GraphQL playgrounds, webhook testing tools, and sandbox environments where you can break things without consequences.
Because here’s what I’ve learned: the moment a technical person at an agency starts building on your platform, writes their first custom integration or automated workflow, that’s when you’ve won. Not when the contract is signed. Not when the implementation is complete. When the first developer says “oh, I can actually work with this.”
That’s what we’re building toward.
Standing on the Shoulders
I’ve met Eric Winch many times, at the CIS user conferences they used to throw at hotels on the San Antonio Riverwalk. If you’ve never been to a software user conference in San Antonio in the spring, imagine hundreds of insurance IT people who’ve spent nine months filing enhancement requests suddenly getting face time with the developers, fueled by Tex-Mex and margaritas on a river patio. It was exactly as productive and chaotic as that sounds. Good times.
Those conferences were another thing CIS got right, by the way. They didn’t just ship software and disappear. They built a community. The Product Advisory Committee (volunteer clients from the underwriting and accounting sides) met three times a year to shape the next build. The users weren’t just consumers of AIM. They were collaborators. That matters more than most vendors realize.
But even beyond the conferences and the community, Eric’s work shaped how I think about software in ways I’m still discovering.
Every time I push back on a design decision that would make our API less flexible, I’m channeling AIM. Every time I insist that a new module needs to be fully API-accessible before we build the UI, that’s AIM’s influence. Every time someone on my team suggests hardcoding a business rule and I say “no, that needs to be configurable,” that’s 15 years of watching AIM’s philosophy prove itself right.
The insurance industry is overdue for a platform that combines deep domain understanding with modern, developer-friendly architecture. A platform that respects the fact that every business unit has its own way of doing things, and treats that as a feature to be supported, not a bug to be fixed. A platform that other businesses can build on, not just build around.
AIM proved it could be done. Plcy.io is proving it can be done again, with 30 more years of hard-won lessons, a modern technology stack, and an unwavering commitment to the same core principle:
Build the kitchen, not the menu.
The best chefs will figure out the rest.