Insurance management software: build or buy?

Buy packaged insurance management software if your business looks like the vendor's demo: one line of business, a standard policy-to-claim flow, and payouts that follow a fixed commission table. Build your own when your margin depends on the parts the package treats as an afterthought, usually payouts, document intake and the handoffs between your team and partners. We built a custom insurance MIS for Greenwin that cut manual data entry by about 75%, and the reasons it made sense are the same five tests we would run on any agency or broker today.

What packaged tools get right

We are not anti-package. A good off-the-shelf platform gives you a policy register, renewal reminders, a basic CRM and a reporting screen from week one, with no engineering team to hire. For an agency writing one product through two or three carriers, that is often all you need, and paying a monthly licence is cheaper than owning code.

The trouble starts at the edges. Packaged insurance software is designed around the most common agency, and most growing agencies stop being common fairly quickly. A second line of business, a sub-agent network with its own payout rules, or a carrier that sends policy documents as scanned PDFs is enough to push work back into spreadsheets.

Where packages break first

In our experience the failure is rarely the policy register. It is the work around it:

• Payouts. Commission splits across sub-agents, carriers and product lines rarely fit a single rate table. When the tool cannot model them, someone recalculates them in Excel every month, and that sheet becomes the real system.
• Document intake. Policy schedules, proposal forms and claim papers arrive in every format. If the package only accepts typed data, a person is still re-keying every document.
• Coordination. Status updates that live in WhatsApp groups never reach the platform, so the dashboard shows what was true last week.
• Ticketing. Customer and partner queries end up in a separate helpdesk or a shared inbox with no link to the policy record they are about.

If two of those four describe your week, a configuration change will not fix it. The package was built for a simpler operation than the one you run.

Five tests before you choose

Run these against your own last 30 days before you sign a licence or brief a developer:

• The re-keying test. Count how many times the same customer or policy detail is typed by a person between first contact and payout. If it is more than twice, you need document extraction, which few packages do well.
• The payout test. Hand the vendor your three messiest commission cases from last month and ask them to configure those, not their sample data. If they cannot do it in the trial, they will not do it after go-live.
• The status test. Pick five open claims and ask your team where each one stands. If the answer needs a phone call or a chat search, the tool must replace that channel, not sit beside it.
• The access test. List who should see what: head office, branch, sub-agent, partner. If the package offers admin and user only, you will either over-share data or lock people out.
• The change test. How often did your process change in the last year? A new product or partner every quarter favours software you control. A process that has not moved in three years favours a package.

Our rule of thumb: fail one test, buy and work around it. Fail three or more, the workarounds will cost more than a build within a year, because every workaround is a person doing the work by hand.

Build vs buy, side by side

• Time to first use. Buy wins. A package is usable in days. A custom build needs a scoped first release, and you should expect weeks before the team moves off spreadsheets.
• Fit to your payouts and workflows. Build wins. You model your actual commission rules and approval steps instead of bending them to a template.
• Document handling. Build wins when volume is high. An extraction layer that reads incoming documents and fills records removes the biggest single source of manual work.
• Running cost. Buy is predictable per seat. Build is mostly upfront, then hosting and maintenance, and does not grow with headcount.
• Control. Build wins. The data model, roles and roadmap are yours, which matters once partners and auditors start asking for reports the vendor never planned.

What we would do for most growing agencies: buy for the first year if you pass the tests, and keep a written list of every workaround. When that list reaches three items that each cost someone hours a week, that is your build brief, already written.

What we built for Greenwin

Greenwin ran policy issuing, claims, payouts and team coordination across spreadsheets and WhatsApp threads. The same data was re-typed at every stage and the real status of a claim lived in someone's head. It worked at low volume and became the bottleneck as the book grew. Measured against the tests above, they would have failed the re-keying, payout and status tests outright.

We built a centralized insurance MIS covering the full lifecycle: policy issuing, claims, payouts, ticketing and team coordination, with role-based access so each person sees what they should. The repetitive data entry is handled by an AI extraction layer that reads incoming documents and fills the records, with a human check on anything it is not sure about. Payout management and built-in ticketing replaced the spreadsheet-and-chat workflow entirely. The stack is Next.js, Node and Postgres on AWS.

The numbers: manual data entry down by roughly 75%, end-to-end processing about 5x faster, and around 4 hours saved per employee per day. For a team of ten people, that arithmetic is 40 hours a day moved from copy-paste to customer work. None of that came from a better policy register. It came from fixing intake, payouts and coordination, the exact areas packages handle worst.

Questions to ask any vendor, including us

• Show me a client in production with a payout model as complex as ours, and what it does at month end.
• What happens to a scanned document that your system cannot read with confidence?
• Can a sub-agent see their own payouts without seeing anyone else's?
• Who owns the data and the code if we stop paying?
• What did your last client still do in a spreadsheet six months after go-live?

The last question is the one that tells you the most. Every vendor has a demo. Very few can tell you honestly what their software did not replace.