The MGU Technology Decision: Don't Pay a Consulting Army to Build What Already Exists

In the MGU world, that second mistake shows up often. A company decides it needs better CRM, AMS, underwriting workflow, reporting, compliance tracking, bordereaux, producer visibility, and management dashboards. Then someone says the magic words:

"We can just build it in Salesforce."

That sentence sounds reasonable. Salesforce is powerful. Salesforce is trusted. Salesforce is flexible. It has APIs, security, workflows, dashboards, permissions, reporting, and a massive ecosystem. All true.

But here is the question that matters: Do you want to buy a platform that already understands insurance, or do you want to spend the next year teaching a general-purpose platform how an MGU actually works?

That is the decision. And in my experience, it is not theoretical. I have been directly involved in three CRM and AMS upgrades and implementations. I have seen the movie from multiple seats in the theater.

What three implementations taught me

At PacificComp, we went through an upgrade and new deployment. Later, with CopperPoint Insurance Company after the acquisition of Alaska National, we had to deal with two very different starting points. CopperPoint was operating on GoldMine. Alaska National had no real CRM structure and was largely operating out of Microsoft Office.

That meant we were not just upgrading technology. We were creating operating discipline, data structure, workflow consistency, visibility, and management reporting from the ground up.

We worked with ReSource Pro on scope and PwC on implementation. Smart people. Serious firms. Capable teams. And it was still tedious. It took months. It required endless meetings, process mapping, configuration decisions, translation between business users and technical people, and all the normal friction that comes with trying to make a broad enterprise tool fit a specialized insurance operation.

That is not a criticism of the people involved. It is a criticism of the economic model.

When the platform does not already understand your business, you pay other people to teach it. That is an expensive tuition bill.

The temptation of the custom Salesforce build

A custom Salesforce build appeals to smart executives because it sounds like control. You can build exactly what you want — every object, field, workflow, permission, approval, dashboard, and automation. You can design around your own underwriting process, your own producer management, your own compliance model, your own submission intake, and your own reporting structure.

That sounds wonderful. It also sounds like building your own railroad because you need to ship freight. Yes, you can do it. But you had better understand the cost, the time, the risk, and the maintenance burden.

A custom Salesforce implementation for an MGU is not just a CRM project. It becomes a software product. You need product ownership. Architecture. Data governance. Implementation discipline. Internal champions. Ongoing development. Support. Someone to maintain the custom logic every time the business changes or Salesforce updates.

The hidden cost is not the first invoice. The hidden cost is the permanent dependency.

That dependency may be worth it for a very large, mature, highly specialized organization with unusual workflows and internal technology talent. Some companies truly are different enough that they need to build. But most are not. Most MGUs do not have a technology problem because they lack imagination. They have one because their workflows, data, and operating model are trapped in systems that were never designed for delegated underwriting authority.

Why purpose-built usually wins

This is where Novidea becomes interesting. Novidea is built on Salesforce infrastructure, but it is not a blank Salesforce canvas. It is an insurance management platform designed for brokers, MGAs, and MGUs. That distinction matters.

You still get the benefits of Salesforce underneath — security, cloud infrastructure, APIs, extensibility, workflow tools, reporting, the broader ecosystem. But you are not starting with a generic CRM and asking consultants to invent the insurance layer from scratch. The insurance layer is already there.

For an MGU, that means the system already understands the operating reality: submissions, quotes, binders, policies, endorsements, renewals, claims visibility, compliance requirements, producers, capacity, bordereaux, reporting, and the need for front-office, middle-office, and back-office data to work together. That is a very different starting point.

The best technology decisions often come down to reducing unnecessary degrees of freedom. Too much flexibility sounds like an advantage until you realize every open decision has to be debated, documented, configured, tested, trained, governed, and maintained. A purpose-built system narrows the choices to the ones that matter.

That is not a limitation. That is leverage.

The Kinetic Insurance lesson

At Kinetic Insurance, we started from scratch. That is usually the most dangerous situation — there is no inherited system to blame, but also no established operating structure to build around. You have to decide what the company is going to become while building the machinery that will run it.

We chose Novidea. We were up in 90 days with robust functionality. After six months, the platform did everything we wanted. No outside consultants.

That last sentence is not a small point. It is the whole point. The difference between "we need a consulting firm to scope and implement this for months" and "we can stand this up, operate, learn, and improve inside the platform" is a massive business difference. One path burns time and money before the business gets value. The other gets the business operating, learning, and improving quickly.

That speed matters because technology projects are not judged by how elegant they look in a steering committee deck. They are judged by whether the business gets better:

Those are the questions that matter.

Why legacy AMS platforms struggle in the MGU world

This is also why legacy AMS platforms like Applied Epic and EZLynx are often not the right answer for an MGU. They are not bad systems. In their lanes, they can be very good. EZLynx has historically been strong with small to mid-sized agencies, particularly in personal lines and agency workflows. Applied Epic is a major platform for retail agencies, including larger commercial lines operations.

But an MGU is not just a retail agency with extra steps. An MGU has delegated authority. Underwriting decisions. Program management. Capacity relationships. Bordereaux obligations. Compliance oversight. Producer management. Profitability questions by program, class, state, producer, carrier, and risk characteristic. That is a different animal.

A retail AMS is built primarily around managing clients, policies, documents, activities, certificates, renewals, commissions, and agency servicing. An MGU platform has to manage underwriting workflow, production control, authority, appetite, risk selection, compliance, bordereaux, program performance, and operational visibility. Those are not cosmetic differences. They are architectural differences.

Trying to force an MGU operating model into a traditional AMS often leads to workarounds. Workarounds lead to spreadsheets. Spreadsheets lead to inconsistent data. Inconsistent data leads to bad reporting. Bad reporting leads to bad management decisions.

That is how technology debt quietly becomes operating debt.

The real cost is not software

Most executives compare software by license cost. That is understandable, but incomplete. The real cost of technology is not the subscription. The real cost is:

• Time to value
• Implementation drag
• Process confusion
• Consultant dependency
• Bad data and poor adoption
• Workflow friction and reporting gaps
• Delayed decisions, rework, and opportunity cost

A cheaper system that requires twelve months of consulting, fifty internal meetings, and constant workarounds is not cheap. A flexible system that requires you to build every insurance workflow from scratch is not flexible in the way management usually hopes — it may simply be unfinished. A legacy system that works for retail distribution may not be wrong; it may just be wrong for delegated underwriting.

Good operators do not ask, "What can this system theoretically do?" They ask, "What does this system already do well, and how much pain will we suffer to get the rest?"

The better question

The question is not whether Salesforce is good. Salesforce is good. The question is not whether Applied Epic or EZLynx are good. They are good for the right use cases. The question is whether the platform fits the job.

For an MGU, the job is not generic CRM. It is not retail agency management. It is not contact tracking with some insurance fields added later. The job is to run an underwriting business with visibility, discipline, compliance, and speed. That means the platform needs to support the way an MGU actually makes money and manages risk:

• Submission intake
• Quote and bind workflow
• Producer management
• Underwriting authority
• Compliance review
• Policy lifecycle management
• Capacity and carrier relationships
• Program performance
• Bordereaux and reporting
• Management dashboards
• API-driven connectivity
• Data visibility across the business

If those things are native to the platform, you are starting ahead. If those things have to be invented by consultants, you are starting with a mortgage.

The lesson

The older I get, the more I respect simple decisions that avoid unnecessary complexity. A purpose-built MGU platform on top of Salesforce gives you an attractive combination: enterprise-grade infrastructure with insurance-specific operating functionality. That is a powerful pairing.

A custom Salesforce build gives you maximum flexibility, but it also gives you maximum responsibility. For some organizations, that tradeoff is worth it. For many, it is a very expensive way to relearn what specialized platforms have already solved. Legacy AMS platforms can be excellent in the retail agency world, but MGUs need more than agency management — they need underwriting management, program control, compliance visibility, and data-driven decision-making.

My own experience has made the lesson clear. When we had to scope, configure, and implement from a less specialized starting point, the process was tedious and took months. When we started Kinetic Insurance on Novidea, we were live in 90 days, had robust functionality, and within six months the platform did what we needed it to do. No outside consultants.

That is not just a technology outcome. That is a business outcome.

The best technology does not make you admire the implementation project. It makes the business run better. And in the MGU world, that is the whole game.