Ptally vs building a rating engine in house
Build or buy? An honest comparison of writing your own insurance rating engine with Ptally: engineering cost, testing, audit trail, versioning, serving at aggregator volume and maintaining rate changes.
Building your own rating engine makes sense if you have a strong engineering team, a small number of simple products and a reason to own every line of code. For most insurers and MGAs, buying a platform such as Ptally is cheaper and faster, because the rater itself is the easy part. The hard part is proving it prices correctly, recording every change, serving it reliably at volume and keeping it right as rates change. That work does not get smaller when AI writes the first version.
The first version is no longer the hard part
General AI tools can now write a working rater in an afternoon. Give Claude or ChatGPT a rating guide and it will produce a Python function that takes the inputs, looks up the factors and returns a premium. For a simple product, that function may well be correct.
This has changed the build versus buy question. A few years ago the main cost of building in house was writing the rating logic. Today the main cost is everything around it. Our article on what a rating engine costs makes the same point: testing, version control, approvals, audit trails, performance at aggregator volume and ongoing maintenance are the parts that take most of the effort.
Side by side
| Ptally | Build in house | |
|---|---|---|
| Upfront cost | None. Free to build, no implementation fee | Developer time from day one |
| First version | Built from your rating guide, spreadsheet or filing, with AI | Quick with AI coding tools |
| Model format | Readable JSON of ordered steps that underwriters can review | Program code that needs an engineer to review |
| Testing | Regression test suite in every model, run on every change | Only what you build and maintain |
| Versioning and approvals | Draft, approve, publish; full version history | Only what you build |
| Audit trail | Every quote tied to the version that priced it, with a debug trace | Only what you build |
| Serving | Real-time API, embedded forms, chat and voice; proven at aggregator volume | You host, scale and monitor it |
| AI client access | MCP server for Claude, ChatGPT and Cursor, with tests and approvals | Your AI tools edit your code directly |
| Rate changes | Draft, test, review the differences, approve | A code change and a deployment |
| Ongoing cost | Up to 1% of GWP, a flat fee per model, or Enterprise terms | Engineering, hosting and support for the life of the product |
| Control | Self-host option on Enterprise | Complete |
What you have to build beyond the rater
Testing
A rater that is right today can be wrong after the next change. You need a suite of test quotes, each with a full set of inputs and an expected result, covering the actuary's worked examples, both sides of every band boundary and every decline and referral rule. The suite has to run on every change and someone has to keep it up to date. In Ptally every model carries its own test suite, and it runs on every change. We explain why this matters in Every rate change needs a test suite.
Versioning and approvals
A regulated product needs to show who changed a rate, when, why and who approved it. In house, that means building draft and live versions, an approval step and a history that cannot be edited. Git gives you some of this for code, but pricing and underwriting staff rarely work in Git. Ptally puts every version through draft, approval and publishing in the dashboard, and keeps the full history.
Audit trail for every quote
When a customer, regulator or auditor asks why a quote was priced as it was, you need to know which version priced it and how each factor was applied. Every Ptally quote records the version that priced it, and the debug trace shows every input, lookup, formula and rule that fired.
Serving at volume
A function on a laptop is not a quoting service. Live products need an API that stays available and fast at peak, which on a price comparison website can mean very large spikes in traffic. That means hosting, scaling, load testing, monitoring and someone on call. Ptally has served over 50 million quotes and runs live on aggregators. Our article on pricing for aggregators covers what that demands.
Maintaining rate changes
Rates change for claims inflation, new territories, tax changes and competitor moves. Each change has to be built, tested, approved and released. If every change needs a developer, the pricing team waits for engineering time, and maintenance can cost more than the original build over the life of a product. In Ptally a rate change is a short process: make it in a draft, run the tests, review the differences, then approve and publish. See our guide to the rate change process.
Readability
AI generated code can be correct and still hard for an underwriter or actuary to check. A Ptally model is a file of named steps (lookups, calculations, transforms, exclusions and referrals) that people and AI clients can both read, so review does not depend on whoever wrote the code.
Using AI on either path
AI is useful whichever way you go. The difference is what it works against. In house, an AI tool edits your code, and your own tests and processes decide whether the change is safe. With Ptally, Claude, ChatGPT or Cursor connect over the MCP server to read, validate, test and edit draft models. The server validates every change and records it in the audit trail. Agents cannot publish. People approve every release.
When building in house is the better choice
- You have a strong engineering team with capacity to own the engine for years, not just to build it.
- You have a small number of simple products with infrequent rate changes.
- Rating is tightly bound to proprietary systems and you need complete control of the code.
- You are prepared to build testing, versioning, approvals, audit and serving yourself.
When Ptally is the better choice
- You want engineering time spent on your product and distribution, not on rating infrastructure.
- You need testing, version control, approvals and an audit trail from the first release.
- You quote through APIs, aggregators, embedded forms or chat and need them to stay up at peak.
- Your pricing team wants to make rate changes without waiting for a deployment.
- You want to pay as premium is written. On the Performance plan that is up to 1% of GWP, with no upfront cost.
If you would rather not build the model yourself, Ptally's pricing experts can build it from your documentation, with no implementation fee.
A middle path
If you have already built a rater, it is not wasted work. Its outputs make the best possible test suite. Run a large set of quotes through it, record the results and use them to prove a Ptally model prices the same, as described in replacing a spreadsheet rater.
Next steps
See how a model is built and tested on the developer page, how quotes are priced through the API, and the pricing plans. For more on using general AI tools with pricing models, read using Claude and ChatGPT to build pricing models.