Most MGA software decisions start in the wrong place: a demo. Demos are where feature lists live, and feature lists converge, every serious vendor in this market rates, quotes, binds, documents, and reports. What does not converge is how the software reaches you: what has to go live at once, who carries the implementation, who owns the data afterward, and what the spend looks like in year three. That is the delivery model, and it is the actual decision.
One disclosure before anything else, so you can weight every word that follows: NTIS sells one of the three delivery models described in this guide, phased builds. We have built and run MGA systems since 2019, and the team behind this guide is on record. We flag our stake plainly when we get there, and we have tried to be as specific about when the other two models are the right answer as about when ours is, because they often are.
Start with your shape, not their features
Before you look at a single product, put four facts about your own operation on paper. Together they decide more of this purchase than anything a vendor will show you.
Your premium band. An MGA writing $10M–$50M in GWP sits in an awkward middle: too much book to keep running on spreadsheets and email, not enough budget or staff to procure software the way a carrier does. Most of the pain in this market comes from operators in that middle buying tools designed for one of the ends.
Your team size. A team of 8–30 people has no slack department. The people who would validate migrated data, sit in vendor workshops, and test new screens are the same people processing today’s submissions and closing this month. Whatever you buy, your team’s spare hours are the binding constraint, and the honest vendors will tell you what they need from those hours before you sign.
Your technical staff. Whether you have anyone in-house who can own an integration, read an export, or hold a vendor’s technical claims to account matters more than any feature. If the answer is no one, then delivery models that hand you configuration responsibility are quietly handing you a hiring decision too.
Your programs. An MGA running 1–3 programs has different needs from one running a dozen. Fewer programs means the workflows, intake, rating handoff, binding, bordereaux assembly, repeat with high volume and low variation, which rewards fixing the workflow over replatforming the core. Many programs across many lines starts to look like carrier-scale complexity, which rewards carrier-scale software.
One more input worth writing down before any vendor call: the trigger. Something external is forcing this decision, a carrier tightening its reporting demands, a program launch with a date on it, producers drifting toward markets that quote faster. Name it, because the trigger sets your real deadline and your real tolerance for implementation risk, and every model handles those differently.
That band ($10M–$50M GWP, 8–30 staff, 1–3 programs) is the shape we work with, and we have written up who we work with and where we draw the line in detail. If you want a structured way to get your own inventory down, the MGA systems checklist walks through every system, spreadsheet, and carrier portal your book touches.
The three delivery models
Every credible option in this market delivers through one of three models. All three are legitimate. The failure mode is buying a model built for a different shape than yours.
1. Enterprise core suites
Guidewire, Duck Creek, Majesco, and OneShield primarily serve carrier-scale core systems, policy administration, claims, and billing for insurers. Buying one is a program, not a purchase: formal procurement, an implementation partner, dedicated internal staffing, and a budget conversation that happens at board level.
When it’s the right answer: you operate at carrier scale or inside a carrier-backed structure, you have an internal IT function that will own the platform, your requirements span many programs, lines, and jurisdictions, and your board has approved a multi-year commitment. If that describes you, buy core software built for that scale and staff the program properly. A phased builder or a no-code configurator is the wrong tool for that job, and most of this guide is not for you.
When it isn’t: you are a lean MGA team hoping an enterprise core will arrive like a product. It arrives like a project, and the project is staffed by you.
2. Configurable no-code platforms
INSTANDA, Insly, and Genasys serve MGA and insurer digital distribution, hosted platforms where your products, rating, and customer journeys are configured rather than coded, often by business users. The start is typically a lighter lift than an enterprise core program, and the vendor runs the infrastructure.
When it’s the right answer: your products are close to standard, you are launching a new program or distribution channel and speed to market matters more than fit, your team is willing to shape its process around the platform’s conventions, and you would rather rent configuration than own a system.
When it needs a harder look: two structural facts, neither of them a criticism. First, your product configuration lives on the vendor’s platform, so the data-ownership and exit questions in the framework below carry double weight, get the answers in the contract, not the demo. Second, the parts of your operation the platform doesn’t model stay outside it, still manual. If your real pain is the month-end reporting scramble or the re-keying between systems you intend to keep, configuring a new quoting front-end doesn’t touch it.
3. Phased builds, what we sell
Full disclosure: this is NTIS’s model, so read this section as a vendor describing its own product. A phased build keeps the systems that already work (usually the AMS) and delivers the single highest-friction workflow first, as a working system in production, with each next phase approved only on the evidence of the last. In practice, the first phase is usually a broker rating portal your producers quote through, a submission-to-issuance workflow that ends the re-keying between systems, or a carrier reporting layer that assembles bordereaux from the systems and spreadsheets you actually run. Everything connects to what you already have through deliberate integrations and migration work rather than replacement, and where AI earns a place (intake extraction, classification suggestions) it runs as governed AI with a human approving every recommendation before it touches your book. The sequencing logic is written up in our method.
When it’s the right answer: your core basically works and the pain is in the workflows around it; your team has no spare capacity to run a migration on top of their jobs; you want each spend gated on the results of the last instead of committed up front; and you want to own what gets built.
When it isn’t: you genuinely need a full core replacement on a fixed date, or you are launching a standard product on a greenfield book, where a configurable platform will likely get you writing sooner. We have turned both of those situations away, and the section at the end of this guide names them plainly. The complete argument (including the cases where a big-bang replacement genuinely wins) is laid out in phased vs rip-and-replace.
The evaluation framework
Whichever model you lean toward, score the candidates the same way. Seven criteria, each scored 1–5, and scored from evidence in writing, not from a demo. Anything you can only score from a demo is a 2 until proven.
| Criterion | The question it answers | Evidence that counts |
|---|---|---|
| Implementation risk | How much has to go live at once before you see any value? | A plan whose first milestone is small, dated, and in production, not a chart that ends at “go-live.” |
| Works with what you have | Does it connect to your AMS, raters, and carrier portals, or quietly require replacing them first? | Your named systems in the scope document, with the integration approach for each. |
| Data ownership | Whose schema is it, and what do you get on exit day? | A contract clause covering export format, cost, and timing, read before signature. |
| Real references | Has this vendor done this for an MGA your shape? | An operator your size who will take your call. Not a logo slide. |
| Security posture in writing | What specific practices protect your book and your carriers’ data? | Named practices in the agreement itself, not a badge on a deck. |
| Total cost over three years | What does year three cost, not month one? | Every line in one number: licenses, implementation, integrations, your team’s hours, seat growth. |
| Capacity honesty | What does this ask of your team, weekly, for how long? | A vendor who names the number unprompted, and a number your calendar can absorb. |
Two of the seven deserve double weight: implementation risk and total cost over three years. They are where MGA software purchases actually fail, not on a missing feature, but on a go-live that never arrives or a year-three invoice nobody modeled. What belongs inside the three-year number is itemized line by line in the MGA technology cost guide. On the works-with-what-you-have criterion, the most common trap is treating the core as the problem when the workflows around it are; we wrote a separate piece on whether you have to replace your AMS before you accept that framing. On security, ask every candidate for their practices in writing and compare them against how we handle security, including us.
If AI appears anywhere in a vendor’s pitch (intake extraction, classification, document drafting) score it under implementation risk and security, not as its own magic column. The standard to hold it to is simple and non-negotiable: a human approves anything that touches your book, and every recommendation is logged with its reasoning. What that looks like in practice, and the failure modes when it’s missing, are covered in our guide to AI underwriting guardrails.
Then ask the sharper question, of us as much as anyone else: which mundane, redundant work actually leaves your team, and what corrects it when it gets something wrong. Our answer is an AI Operational Workforce that takes intake, chasing, matching and assembly, with feedback loops that correct it as it goes, and a person who still owns every decision that touches rating or binding.
On capacity honesty, since we are holding vendors to it, here is our number: a phased build asks about 3–5 hours per week from your team, and we say so before an agreement is signed. Whatever a vendor’s number is, the disqualifying answer is not a big number. It’s no number.
The costs nobody quotes
The license line is the most visible cost and rarely the largest. Before you compare two proposals, force both into the same three-year frame and make sure these lines exist in it:
- Implementation and configuration beyond the license. The work of turning a product into your product, someone pays for it, whether it appears on the quote or arrives later as change orders.
- Integration work. Connecting the new system to the AMS, the raters, the carrier portals, and the accounting stack. If the proposal says “API available,” that is a capability, not a plan.
- Data migration and validation. Moving records is cheap; proving they moved correctly (before a live renewal proves it for you) is the real line.
- Your team’s hours. Workshops, testing, data validation, retraining. Unbudgeted internal time is still cost; it just comes out of service levels instead of the bank account.
- Adoption. A portal producers don’t log into and a workflow underwriters route around cost exactly as much as ones that work. Why that happens (and what actually gets producers to switch) is the subject of our broker portal adoption guide.
- Seat and volume growth. Per-seat and per-policy pricing that fits today’s team can become one of the largest lines in the budget by the time you’ve grown into the plan you bought the software for.
- Exit. The cost of leaving (export, rebuild, retraining) is set on the day you sign, not the day you leave.
You will notice this page prints no dollar figures for any of these. That is deliberate: any number quoted without your inventory would be fiction, and this market has enough of that. The MGA technology cost guide breaks down each category and how to bound it for your own scope.
Questions that separate vendors fast
You can compress most of the framework above into a first call. Five questions do the sorting:
- “What is the smallest first deliverable you would propose for us, and when is it in production?” Model-revealing. You will hear a phase, a configuration sprint, or a program plan, and now you know what you’re actually buying.
- “Who owns the data model, and what does an export cost on the day we leave?” If this needs to be escalated to someone else, escalate the vendor off the shortlist until it comes back in writing.
- “Which MGA of our size can we call?” Not a case study. A phone number.
- “What will you need from our team, in hours per week?” The capacity-honesty test. Vague answers here become your nights and weekends later.
- “What part of our operation is a bad fit for your product?” Every product has one. A vendor who can’t name theirs is telling you how the whole engagement will go.
The long-form version (with the answers worth hearing and the ones that should end the meeting) is in questions to ask MGA software vendors.
When we’re not the fit
Since we’ve told you what we sell, here is where we would score badly on our own framework, and what to do instead.
- You’re running an enterprise RFP. Formal procurement, security questionnaires scored by committee, an implementation-partner ecosystem. That process exists to buy enterprise core suites, and for carrier-scale operations it works. We don’t bid into it.
- You need the vendor to own admitted personal-lines filing content. If the software must carry rate, rule, and form filing responsibility for admitted personal lines, buy from vendors whose product is built around that regulatory machinery. Our work assumes your team owns the insurance content; we build the systems around it.
- You have a big-bang deadline. If a hard date requires everything to cut over at once, phasing is the wrong shape for your problem, and we will say so in the first meeting rather than the last.
The longer version of this list (the shapes we take on and the ones we refer out) is on who we work with.
The no-stakes way to get your shape on paper: a mapping session. 60–90 minutes with people who run MGA systems every day; you leave with your systems, spreadsheets, and three costliest frictions on one page. The map is yours whether or not we ever work together. Book a mapping session.
The sequence, then: shape on paper first, delivery model second, vendor shortlist last. Score whoever survives against the seven criteria, from evidence, in writing, over three years. Two adjacent decisions sit alongside the shortlist: whether to build, buy, or modernize in phases, and how long implementation actually takes once you have chosen. If the map points to a phased build, the MGA Systems Assessment is the next gate: 2–3 weeks against your actual inventory, ending in a priced, dated plan you could hand to any builder, including one that isn’t us. And if the map points to an enterprise suite or a no-code platform, take that answer. The point of choosing by shape is that the software fits the MGA, not the other way around.