The reason new products usually take months is that most platforms treat each one as a development project. Ours separates the underwriting engine from the product configured on top of it. Build the engine once and cover it with automated checks, and launching becomes a matter of describing a product rather than building the machinery again.
These are working timescales for the build itself, assuming rates, wordings and appetite are decided and someone on your side is available to review as we go. They are short because of how the platform is structured: a product is configuration on a shared engine, not a build of its own. If a case is genuinely more complicated we will say so before we start rather than after.
| Timescale | Scope | What it covers |
|---|---|---|
| 1–2 days | A change to a live product | Revised rates, a new endorsement or wording, an adjusted appetite rule, a new referral trigger, a scheme variant for one distribution channel. Tested and released without disturbing anything else you write. |
| 1–2 weeks | A new product on the existing engine | Its own question set, rating structure, appetite and referral rules, endorsement library, and full document suite. Quote, refer, bind, adjust, renew — complete, not a quote form with the rest to follow. |
| 2–4 weeks | A new class of business | A class we have not built before — marine, specialty, anything with its own conventions — or one needing external data we do not already consume, a materially different lifecycle, or reporting in a carrier’s own format. The engine still holds; the work is at the edges. |
| 4–8 weeks | A complete platform | A new operation stood up end to end: broker and underwriting portals, users and permissions, document production and carrier reporting, configured and branded for you. Migration of an existing book runs alongside rather than after — see moving an existing book. Products then follow at the timescales above. |
Days for a change, a week or two for a product, weeks rather than quarters for a whole platform. A supplier quoting months for a product variant is rebuilding the engine every time.
This matters more than the numbers above, because once the build drops to weeks it stops being the constraint at all. We have sat on the insurer side of these launches as well as the supplier side, and in almost every one, something else was the long pole.
Carrier sign-off is usually the constraint. Rates, wordings and appetite need agreement, and that runs at the speed of your capacity provider, not your software supplier.
Wording and legal review follows the same pattern. We can produce the document suite in days; approving what it says takes as long as it takes.
Your own testing capacity is the third. Real underwriters need to run real cases through it, and they have day jobs. We would rather wait for proper testing than launch something that quotes confidently and wrongly.
Data availability occasionally bites, where a class needs information that is expensive or simply does not exist at the granularity the rating wants.
The practical implication is worth taking seriously: start the carrier conversation and the wording review on day one, in parallel with the build. Do that and the timescales above are the whole story. Leave them until the software is finished and you will wait months for a product that was ready in weeks.
Rating, referral, binding, adjustment, renewal and document production are built once and shared. A new product describes its questions, rates, rules and wordings — it does not reimplement the lifecycle.
Schedules and statements are generated from the rated outcome itself rather than maintained as separate templates. A rate or wording change appears in the paperwork automatically, which removes the slowest and most error-prone part of most launches.
Automated checks run before anything reaches production, including full quotes run end to end with their premiums and terms compared against known-good results. Speed on a live book comes from being able to prove you have not broken the other products, not from moving carefully.
Appetite, referral triggers and pricing behaviour are held as rules keyed to the carrier they belong to, so two carriers on the same product can differ without either being a special case.
We work through the question set, the rating basis, what binds and what refers, and the documents the product must produce. Ambiguity found here is cheap; found in testing it is not.
Configured against your appetite, with quotable cases available early so you are reacting to something real rather than to a specification document.
Your underwriters run genuine risks through it, including the awkward ones. Findings are fixed and re-tested, and each fix gets a permanent automated check so it cannot come back.
Live with a small number of brokers first, watching real submissions, before wider release. Adjustments at this stage are days, not a new phase of work.
Tell us the class, the appetite and who is carrying the risk, and we will tell you honestly which of the timescales above it falls into — and what would make it the slower one. We have no attachment to any particular line of business; if you can define it, we can build it. See also AI underwriting and what a complete platform includes.
Send us an enquiry →Or email hello@apdrit.com