Platform, not product
Why we build standard insurance products once and connect them to everything. There are two ways to build software for underwriting agencies, MGAs, coverholders and insurers. The difference is less about technology than about where the cost of building sits, and who pays it.
The first is to build a product. The vendor supplies a system, and each client pays to make it work for its own business. The wording is loaded, the questions are designed, the rater is built, the schedule and documents are templated, the bordereau is mapped and the reports are written. Each of these is a project, and each client pays for its own.
The second is to build a platform. The vendor builds each component once, connects the components to each other, and lets every client use them with its own settings.
Where the build cost sits
In a product model, build cost sits with each client. If twenty agencies want a professional indemnity product, the market pays for twenty wordings, question sets, raters, schedules and bordereau mappings, most of them close variations of each other. Each is then maintained separately. When a law, a tax or a capacity provider’s reporting format changes, the change is made twenty times.
In a platform model, build cost sits with the class. We build a standard product for a class once, and every client that writes that class uses it. The client’s work is choosing settings: its rates, rules, limits, excesses, extensions, referral authority and its own name on the documents. A change to the standard is made once and reaches every client.
This is why a platform does not need to charge a build fee. The cost has not been discounted. It has moved from the client to the class, and it is recovered across every client that uses the class, through a fee that follows the business written. The more clients use a class, the smaller each one’s share of the cost.
Where a client needs something that is genuinely its own, that is separate work. Where the need turns out to be common, it becomes part of the standard.
What “already connected” means
A rater on its own is a calculator. A standard product is useful from the first day because its parts are connected to each other and read from one record.
The questions feed the rater. The rater feeds the schedule and the policy documents. The bound policy feeds the bordereau and the reports. A broker’s answers are captured once and used at every later step. Nothing is rekeyed between systems, because there is one system.
This matters more as data standards tighten. Capacity providers and markets increasingly expect a consistent record of every risk, supplied cleanly by every party in the chain. An agency whose questions, rating, documents and bordereaux already share one structured record can meet that expectation. One whose data sits across spreadsheets and separate tools has to reconcile it first.
Settings, not projects
The main reason to build a platform is what becomes possible once standard products share one record. In a product model, each of the following is a project. On a platform, each is built once for everyone and switched on as a setting.
- Cross-sell. Each client has one record, so the platform knows which classes it holds and which it does not. Common details, such as turnover, are entered once and used by every class.
- Packages. A package is a set of standard products sold together, with shared questions and one schedule. When the products already exist, the package is configuration, and brokers can assemble bundles for a client from standard parts.
- A marketplace. When products share a standard question set and wording, a broker can submit once and compare quotes from several markets on the same terms. A product already on the standard joins without a new project.
- Sales funnels. The same questions and logic can sit in a broker’s industry sales funnel, so a prospect’s first answers carry through to the quote, the policy and the bordereau.
- New jurisdictions. Currency, tax, duties, business identifiers and local law sit in a jurisdiction pack on the same codebase, not in a separate system.
- AI agents. An agent that prepares a submission or checks a bordereau needs structured data and a known wording. A platform supplies both. Decisions to quote and bind stay with the underwriter’s rules and authority.
None of these is free to build the first time. The point is that each is built once for the platform, not once for each client.
One component, many channels
The rater shows the principle at the level of a single component.
We make our raters game-like on purpose. Covers turn on and off, limits and excesses move, and the premium builds line by line as each answer changes it. If a user goes beyond their authority, binding becomes a referral. Immediate feedback makes a rater quicker to learn and more pleasant to use, for an underwriter quoting all day or a broker testing options with a client. It does not reward anyone for choosing more cover or binding faster. It shows the effect of each choice.
The raters are also built for a two-step dialogue:
- A few questions give an indicative price: enough for a prospect or broker to know whether the cover is worth pursuing.
- The remaining questions give a firm, bindable quote within the market’s rules and authority.
Both steps run on the same rater and the same record, so the first answers carry into the second.
One rater therefore serves the underwriter, the broker, the sales funnel and the marketplace. In a product model, that is four builds. On a platform, it is one component used four ways.
What stays with the agency
The usual objection is that standard products make underwriting a commodity. The standard covers the wording and the systems work. Rates, rules, appetite, limits, extensions and service remain the agency’s, and those are what brokers choose between.
For most agencies the main constraint is resources: the people, time and money to build and run systems. A platform that costs less and does more frees those resources for underwriting and distribution.
Insurance has long used standard forms for the same reason. Common language makes cover more predictable and easier to compare, so markets compete on price and judgement rather than on small print.
A platform should also be easy to leave. Clients should be able to take their data out freely, should not be bound by exclusivity, and should ask any vendor how they would leave.
The question to ask
When an agency compares systems, the useful question is not only “how quickly can you configure my product?” It is “who pays to build it, and who pays to change it?”
If the answer is the agency, every new class, package, channel and data standard will be another project. If the answer is the platform, they become settings.
That is the choice Cuttleflow has made. We build standard products once, connect them from the first day, and let cross-sell, packages, a marketplace, sales funnels and AI agents follow from the architecture.
Cuttleflow Pty Limited trading as Cuttleflow Systems is a software provider. It does not hold an Australian financial services licence and does not issue, arrange or advise on insurance.
Cuttleflow Systems · Perspective 27 · 33°53′S · 151°16′E · Sydney