Home / Resources / Diligence questions

25 questions to ask every MGA software vendor, including us.

Ask the questions a demo is built to avoid: who does the work, who owns the data, what's dated in writing, where a human approves the AI, and what it costs to leave. A vendor's reaction to hard questions predicts the engagement better than the demo does. These are the 25 we'd bring, and the same ones we expect to be asked ourselves.

Diligence list NT-R-11Revised 2026-078 min read

Demos are rehearsed. Diligence isn't. Every question below exists because somewhere, a growing MGA didn't ask it and paid for the omission after signature, when leverage was gone. Use the list in the room, in writing, with every vendor on your shortlist. If you want the fuller decision process this list plugs into, it pairs with our guide on how to choose MGA software: that page covers the process, this one is the ammunition.

For each question we've noted why it matters, what a good answer sounds like, and what should worry you. A few cut against us as much as anyone, and where they do, we've put our own answer on the record.

Implementation risk, questions 1–5

1. Who actually does the implementation work: your employees, contractors, or a partner firm?

The team in the demo and the team that delivers are often different people, and the gap between them is where projects go quiet. A good answer names the people, their roles, and how long they've been doing this work. Worry when delivery is handed to a partner network you've never met, or when the answer is an org chart instead of names.

2. How many implementations are you running right now?

Delivery capacity is finite, and a team spread across too many clients answers your emails last. A good answer is a specific, small number and a willingness to put it in writing. This one cuts against us too, so here is our answer in advance: a small number, in writing. Worry about a vendor who says the question doesn't apply because the product "configures itself."

3. How many hours a week will you need from my team, and from whom?

Every implementation is also a project your staff runs on top of their day jobs: underwriters validating data, operations testing workflows. A good answer is a number attached to named roles, not "minimal involvement." Ours, for the record, is 3–5 hours a week, mostly from the people who know your book. Worry when a vendor claims your team barely needs to show up, because that usually means nobody validates anything until go-live.

4. What is the first thing my team will use in production, and when?

"Configured" is not the same as "used." A good answer names a working deliverable, a broker quoting flow, a tracked submission-to-issuance workflow, a reporting layer, and the concrete route to your team touching it. Worry about a first milestone that is an environment, a kickoff, or a data load, with nothing anyone on your side actually uses.

5. Can the work be phased so each phase stands on its own if we stop?

The honest test of any plan is what you're holding if you stop halfway. A good answer describes phases that each deliver working value, with an explicit right to pause between them; that structure is the core of our own method, so we think it's fair to demand of anyone. Worry about all-or-nothing plans where the value arrives only at the end, because the end is the part that slips.

Data & exit, questions 6–10

6. Who owns our data, and in what format do we get it back?

"You own your data" means nothing without a format and a process attached. A good answer is contractual: your data, in a documented open format, exportable on request, without a professional-services invoice. Worry about "we'll work with you on that when the time comes", the time in question is the moment your leverage is lowest.

7. Can we run a full export ourselves, today, without asking you?

Self-serve export is the difference between owning your data and renting access to it. A good answer is a demonstration: here is the button, here is the file. Worry when exports go through a support ticket, because tickets have queues, and one day your renewal deadline will be sitting in one.

8. How will you migrate the data in the systems we run now, and what happens when a record fails validation?

Migration is where implementations actually fail, and this answer tells you whether the vendor has lived through one. A good answer describes a validation report, parallel running, and a plan for the records that don't fit, the shape of careful integration and migration work. Worry about "we have a standard migration tool" with no mention of what happens when your data disagrees with it.

9. What happens to our renewals during cutover?

Your renewal book is the company, and a migration error surfaces on a live renewal in front of a broker or a carrier. A good answer treats renewals as the last thing to move, only after validation passes. Worry when the cutover plan doesn't mention renewals at all.

10. Walk me through leaving you: notice, cost, and what we take with us.

Every vendor can describe onboarding; the confident ones can describe offboarding. A good answer is specific and boring, notice terms, handover format, transition support. Worry when the exit story is vague, because a vague exit is an expensive one.

Timelines & capacity, questions 11–15

11. Show me a dated plan for an MGA our size, not a "typical timeline."

Typical timelines are marketing; dated plans are commitments. A good answer is built against your actual system inventory, with dates the vendor will sign. Worry about a round number quoted in the first meeting, before anyone has seen your systems, a duration offered before diligence is a guess dressed as a promise.

12. When a project falls behind, what slips first?

Every vendor has slipped a project, so the useful information is how they triage. A good answer is honest about the trade (scope trimmed, dates moved, extra review added) and how you'd hear about it early rather than at the deadline. Worry about "our projects don't slip."

13. Who is our named contact, and who covers when they're out?

Implementation quality is mostly the quality of one or two people, and you should know who they are before you sign. A good answer names them and lets you meet them before contract. Worry when the sales engineer in the room won't be on the delivery team and nobody can say who will be.

14. How do you price and approve a scope change mid-project?

Scope changes are certain; the only question is whether the process for them is written down in advance. A good answer is a change procedure with pricing rules agreed before the project starts. Worry when changes are "handled case by case," which means priced at the moment you have no alternative.

15. What is the smallest first engagement you'd propose for us?

The size of the first commitment reveals how a vendor thinks about risk, yours, specifically. A good answer is small, concrete, and reaches production quickly, so the relationship is tested on evidence instead of faith. Worry when the smallest thing on offer is the whole thing.

Security & AI, questions 16–20

16. Where does our data live, who can access it, and how would we hear about an incident?

Submission data is broker data and insured data, and your carrier partners will eventually put these questions to you, so put them to the vendor first. A good answer covers hosting, access control, and incident notification in plain language, without hand-waving. Ask us this one too: our security page is the answer written down in advance.

17. What security documentation can you share before we sign?

The order matters: documentation before contract, not after. A good answer is a concrete package you could forward to a carrier's diligence team tomorrow. Worry about badges on a website with nothing behind them when you actually ask.

18. Where, exactly, does a human approve what the AI produces?

If the product applies AI to underwriting-adjacent work, the approval point is the entire question. A good answer names the step: the model drafts, a named person approves, and the log shows who. That is the standard we hold our own governed AI to, and you should refuse anything looser. Worry about "the AI handles it automatically" anywhere near intake, rating, or classification.

Push the answer further and ask which work is actually being automated, because the defensible split is that mundane, redundant work (reading the submission, chasing the missing field, matching, assembly) runs as an AI Operational Workforce with feedback loops that correct it as it goes, while a person owns every decision that touches rating or binding. A vendor who cannot draw that line for you has not drawn it in the product either.

19. Is our data used to train models, yours or a third party's?

Your submission data describes your programs, your brokers, and your insureds, and it should not become anyone's training corpus by default. A good answer is a plain "no," stated in the contract. Worry about answers leaning on "aggregated" or "anonymized" without defining either term.

20. Can we try the AI feature on our own inputs, without a sales engineer driving?

A scripted demo proves that a demo works. A good answer is public access or a hands-on trial with your own examples, before anyone asks for a signature. It is why we answer it with a 30-day production trial: a working system on your own submissions, which you operate before ever talking to us. Worry when the most heavily marketed capability is the one you're not allowed to touch.

Commercial terms, questions 21–25

21. What is the all-in cost on one page: licenses, implementation, integrations, support?

Not a range, a page. A good answer puts every line where you can see it, including the integration work that often gets quoted separately after signature. Worry about pricing that requires a discovery call to reveal, or a license figure quoted with implementation "to be scoped."

22. What will cost extra in year two that's included in year one?

A cheap first year is a sales tool; the durable costs are seats, environments, integrations, reports, and support tiers. A good answer lists what grows with you and on what basis. Worry when growth pricing is "we'll discuss it at renewal". You'll be discussing it after migration, which is to say, after your leverage.

23. What is the minimum commitment, and what do you have to deliver to earn the renewal?

A vendor confident in the product doesn't need a long lock-in to keep you. A good answer pairs a modest initial term with defined deliverables the renewal depends on. Worry about multi-year commitments justified by discounts on software you haven't seen working.

24. When a milestone slips because of you, what happens to the price?

Symmetry is the test of a fair contract: you carry penalties for late payment, so what is the vendor's equivalent for late delivery? A good answer has the consequence written in, credits, extended support, a defined walk-away right. Worry when the entire risk of vendor delay is priced onto you.

25. Will you attach your answers to these questions to the contract?

Everything above is cheap to say in a demo and expensive to honor in writing. A good answer is "yes" without flinching, because the answers were either true or they weren't. Worry (a lot) about the vendor who answered 24 questions fluently and balks at the 25th.

The pattern to watch: no single answer decides the choice, but the reaction to being questioned does. A vendor who welcomes this list is showing you what accountability will feel like after signature. A vendor who deflects it is showing you the same thing.

What to do with the answers

Ask in writing and insist the answers come back in writing, because written answers survive team changes and demos don't. Put every shortlisted vendor's responses side by side before you compare a single feature. And do it with a map of your own systems in hand, questions land harder when you already know your inventory, your three costliest frictions, and the trigger forcing the decision.

That map is what a mapping session produces: 60–90 minutes, your systems on one page, yours to keep either way. If you want the deeper version, the MGA Systems Assessment turns that map into a dated, fixed-scope plan in 2–3 weeks, the kind of plan question 11 demands, priced against your inventory rather than a generic one. Bring this list to either conversation. We'd rather answer it early than have you wish you'd asked it late.

The first step is free

Bring this list to your mapping session.

A 60–90 minute working session: your systems on one page, your three costliest frictions named, and every question on this page welcome, including the ones that cut against us.