# Swallow vs building a rating engine in house

> Build or buy? A fair look at writing your own insurance rating engine versus using Swallow: testing, versioning, audit, serving at volume and rate changes.

Published 4 November 2025. Category: Comparisons.
Source: https://www.swallow.app/post/swallow-vs-building-a-rating-engine-in-house

Writing your own rating engine can be the right call if you have a strong engineering team, a handful of simple products and a genuine need to own every line of code. For most insurers and MGAs, a platform such as Swallow costs less and gets there sooner, because the rater is the small part of the job. The large part is showing that it prices correctly, recording every change, keeping it up and quick under load, and keeping it right as rates move. AI writing the first draft doesn't shrink any of that.

## Writing the rater is now the easy bit

A general AI tool can turn a rating guide into a working rater in an afternoon. Hand Claude or ChatGPT the guide and you'll get back a Python function that reads the inputs, looks up the factors and returns a premium. For a simple product, it may well be right first time.

That shifts the build or buy question. Not long ago, most of the cost of building in house was writing the rating logic. Now most of the cost sits around it: testing, version control, approvals, an audit trail, staying fast at aggregator peaks, and maintaining it for as long as the product is on sale. Those are the parts this post is about.

## At a glance

| | Swallow | Build in house |
|---|---|---|
| **Getting started** | Talk to us | Developer time from the first day |
| **First version** | AI draft from a description and spreadsheet, a US filing, or built on the canvas | 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** | Tests on every version, expected against actual | Whatever you build and keep up |
| **Versions and approvals** | Draft, approved, published; one draft at a time; approvals by role | Whatever you build |
| **Audit trail** | Every quote records its version, with a debug trace on request | Whatever you build |
| **Serving** | Real-time REST API, embedded forms, voice and chat; built to scale to millions of quotes a day | You host, scale and monitor it |
| **AI clients** | MCP server for Claude, ChatGPT and Cursor; agents draft and test, people publish | Your AI tools edit your code directly |
| **Rate changes** | New draft, run the tests, compare, approve, publish | A code change and a release |
| **Ongoing cost** | Talk to us | Engineering, hosting and support for the life of the product |
| **Control** | Self-hosted enterprise offering | Total |

## The work that comes after the rater

### Tests

A rater that's right today can be wrong after the next edit. You need a bank of test quotes, each a full set of inputs with the answer you expect, covering the actuary's worked examples, both sides of every band edge and each decline and refer rule. It has to run on every change and someone has to keep it current. In Swallow, tests live on each version of the model. Add them one at a time, upload a CSV, or have AI generate a starting set, and the dashboard shows expected and actual results side by side. [Every rate change needs a test suite](https://www.swallow.app/post/testing-insurance-pricing-models) goes into why.

### Versions and sign-off

For a regulated product you need to show who changed a rate, when, why and who approved it. Building that yourself means draft and live versions, an approval step and a history nobody can rewrite. Git covers part of it for code, but underwriters and pricing analysts rarely live in Git. In Swallow every version goes from draft to approved to published in the dashboard, your team's roles decide who can approve, and every step is logged with who did it and when.

### An answer for every quote

When a customer, auditor or regulator asks why a quote came out at a given price, you need the version that priced it and how each factor was applied. Every Swallow quote records its version, and the API can even find the version that was live on a given date. Ask for a [debug trace](https://www.swallow.app/developer/quoting) and you get every input, lookup, formula and rule the engine worked through.

### Staying up under load

A function on a laptop isn't a quoting service. A live product needs an API that's fast and available at peak, and on a comparison site peaks can be sharp. That's hosting, scaling, load testing, monitoring and someone on call. Swallow's engine is built to scale to millions of quotes a day, and the same model serves the API, embedded forms and voice and chat. Our post on [AI for insurance distribution](https://www.swallow.app/post/ai-for-insurance-distribution) covers what each channel asks of a rating engine.

### Keeping rates current

Rates move with claims inflation, new territories, tax changes and the competition. Each move has to be built, tested, approved and released. If every one needs a developer, pricing queues behind engineering, and over the life of a product the upkeep can cost more than the first build. In Swallow a rate change is a short loop: copy the live model into a draft, make the change, run the tests, compare, then approve and publish. The [rate change process](https://www.swallow.app/post/insurance-rate-change-process) sets it out step by step.

### Being able to read it

AI-written code can be correct and still hard for an underwriter or actuary to check. A Swallow model is a file of named steps (lookups, calculations, transforms, exclusions, refers) that people and AI clients can both read, so a review doesn't depend on whoever wrote the code. There's more on that in [human-readable pricing models](https://www.swallow.app/post/human-readable-pricing-models).

## AI works on both routes

AI helps whichever way you go. What changes is what it's working against. In house, an AI tool edits your code, and your own tests and processes decide whether the change is safe. With Swallow, Claude, ChatGPT or Cursor connect to the [MCP server](https://www.swallow.app/developer/mcp), load the rules, start from an example model, validate it and run its tests, without saving anything. The agent hands over the JSON, and a person uploads it to a draft, approves it and publishes it in the dashboard. No MCP tool can create, edit or publish a project.

## Build it yourself if

- You have a strong engineering team with room to own the engine for years, not just to write it.
- You have a few simple products and rates rarely change.
- Rating is wound tightly into proprietary systems and you need full control of the code.
- You're ready to build testing, versioning, approvals, audit and serving as well.

## Choose Swallow if

- You'd rather spend engineering time on your product and distribution than 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 they have to stay up at peak.
- Your pricing team wants to change rates without waiting for a release.

If you'd rather not build the model yourself, send us your rating guide, spreadsheet or filing and [we'll talk you through](https://www.swallow.app/contact) getting it live on Swallow.

## A route in between

A rater you've already built isn't wasted. Its answers make the best test suite you could ask for. Push a large set of quotes through it, keep the results and use them to show a Swallow model prices the same, as described in [moving off a spreadsheet rater](https://www.swallow.app/post/replacing-a-spreadsheet-rater).

## Next steps

Walk through a model being built and tested on the [developer page](https://www.swallow.app/developer), see how quotes are priced through the [API](https://www.swallow.app/developer/api), or [talk to us](https://www.swallow.app/contact). For more on general AI tools and pricing, read [using Claude and ChatGPT to build pricing models](https://www.swallow.app/post/using-claude-and-chatgpt-to-build-pricing-models).