The honest answer to "what will this cost" is a structure, not a number. Any vendor who quotes a figure before seeing your systems is guessing, and any guide that publishes "typical" dollar ranges is doing the same thing with more confidence. What we can give you is the anatomy of the spend: the three ways MGA systems are priced, the multiple that sits on top of the license, and the line items that tend to arrive after you've committed. Budget against the structure, and the quotes stop being surprising.
The three pricing models
Nearly every quote you will see is built on one of three models, and each one shifts risk in a different direction.
Per-seat licensing. You pay for people, not policies. It reads as predictable, but the number to stress-test is not today's headcount. It's the headcount in your growth plan. A price that fits the team you have reads very differently at the team you're hiring toward, and growing MGAs are, by definition, hiring.
Per-policy or per-transaction fees. You pay for volume. This aligns the vendor's revenue with your book, which sounds fair until you notice it's a permanent margin decision made once, in procurement: a fee attached to every policy you will ever write through the system. Model it against the book you plan to have, not the one you have now.
Percentage of GWP. The vendor takes a slice of premium. Read this one most carefully. A rate that looks small against today's book compounds against every year of growth, and it is the hardest structure to renegotiate once your programs run through the system.
None of these is wrong. The question is which line grows fastest under your plan, and whether you or the vendor carries that risk.
The implementation multiple
The license quote is not the deal price. Implementation (configuration, data migration, integrations, training) is usually quoted separately, and it is routinely a major line of its own. That is not a scandal; standing a system up on real MGA data is genuine work. The problem is sequencing: the license number arrives early, in the sales conversation, and the services number arrives late, after you're invested.
The defense is to budget one figure from the first meeting: total cost to a live system your team actually uses. Ask for the services estimate in writing before you shortlist anyone, and treat reluctance to give one as information.
The line items that surface after signature
Five recur often enough that we would put them on every MGA's checklist:
- Integrations billed separately. Each carrier feed, each rater connection, each accounting sync can arrive as its own statement of work. If the integration and migration scope isn't priced in the proposal, it gets priced later, on the vendor's terms, when switching is no longer realistic.
- Migration as change orders. "Standard migration" is quoted before anyone has looked at your data. Once they have, the re-scope tends to arrive as change orders. Ask what "standard" excludes, in writing.
- Per-seat creep. The quote was priced for the team you had at signature. Every hire quietly reopens it.
- Mandatory upgrades. Some contracts make version upgrades both required and billable. You are budgeting for the vendor's roadmap whether you asked for it or not.
- Hosting passthroughs. Infrastructure billed through at the vendor's rate, moving with usage you don't control day to day.
None of these is an accusation. They are questions, and every one of them answered in writing before signature turns the contract into a budget instead of a floor.
The budget line you're actually competing with
Here is the comparison most vendors won't make for you: the real alternative to MGA software usually isn't another vendor. It's another hire. "Cheaper to hire another CSR" is often true in year one, a person is flexible, needs no integration project, and starts next month.
The logic breaks where the work scales with the book instead of with effort. Every renewal adds keystrokes. Month-end carrier reporting and bordereaux assembly grows with every carrier and program you add, on deadlines your carriers set, not you. And re-keying the same submission into three systems doesn't get cheaper with headcount. It gets institutionalized, which is exactly what a tracked submission-to-issuance workflow exists to end. When you weigh software against a hire, weigh it against the third hire, not the first.
The cost you are actually removing is the mundane, redundant work itself (intake, chasing, matching, assembly), which moves to an AI Operational Workforce running with feedback loops that correct it as it goes. What you are not removing is the underwriter, who still owns every decision that touches rating or binding, so price the software against the work it absorbs, not against the judgment it does not.
How our model prices
We publish how our pricing works rather than a rate card, because the honest number depends on scope. The shape: no setup fee and no implementation invoice. We carry the Phase-1 build, and billing starts when you are live and using it. Before that, a fixed-fee Assessment puts your Phase-1 quote and monthly rate in writing, so the number you commit to is priced against your systems, not a template. The full logic is on our pricing page.
How to budget honestly
- Budget total cost to live, not license. One figure, covering software, services, integrations, and migration, before you compare anything.
- Model the structure against your growth plan. Run each pricing model against the headcount and book you intend to have, and see which line compounds.
- Get the five line items above answered in writing. Before signature, not after.
Cost is one axis of the decision, not the whole decision. For the full selection method (requirements, diligence questions, and how to run the process) start with our guide on how to choose MGA software. And if you want the numbers priced against your actual scope rather than estimated from a guide, that is what the MGA Systems Assessment is: a fixed fee quoted in writing, 2–3 weeks, and a phased plan with your numbers on paper before you commit to anything.