We started building Attune in the spring of 2024. The core question was whether we could build a risk scoring model for small commercial insurance applications that was fast enough and accurate enough to give a broker something usable in a client meeting, as opposed to two days after it. By the third quarter of 2025 we were in production with our first early-access agencies. This is what we learned in that first operating year.
I am writing this from the technical side, so the emphasis is on what surprised us about the data and the model, not on product decisions or market positioning. AK covered the business framing in the funding announcement last month. This is the engineer's version of the same period.
Lesson one: carrier appetite data is a harder problem than application data
Before we started, I assumed the hard part of the scoring model would be the risk assessment logic itself: weighting the application signals, calibrating the model across business classes, handling edge cases in the scoring output. That turned out to be difficult but tractable work. The data was cleaner than I expected, the signal relationships were learnable, and the scoring model reached acceptable accuracy on standard BOP applications within a few months of sustained development.
The carrier appetite layer was harder in a way I did not fully anticipate. Carrier appetite guidelines exist in a range of formats: PDFs published in broker portals, Excel rate sheets, email communications from underwriters, and institutional knowledge held by brokers who have placed enough business with a carrier to know the informal parameters that never appear in the official documentation. None of these are designed to be machine-readable. Getting them into a form usable by the system required significant data engineering work that was not in our original timeline estimates.
The second part of the appetite data problem is that it changes continuously. A carrier that was writing small habitational risks actively in mid-Atlantic states in the first quarter of 2025 had tightened considerably by the third quarter, in response to claim trends. That change propagated through informal channels first. The official documentation updated weeks later. If your appetite data is only as current as the last time someone updated the formal documentation, you are generating routing recommendations that are stale by the time they reach a broker.
We now treat appetite data maintenance as an ongoing operational function, not a periodic product update. That was not the original plan. It should have been.
Lesson two: brokers do not want a score, they want an explanation
The initial version of the scoring output returned three things: a numeric risk score on a 100-point scale, a risk tier label, and an indicative premium range. We thought that was a complete output. It was not.
When we started running early-access sessions with brokers in mid-2025, the feedback came back consistently: the number does not help. A broker sitting across from a client does not say "your risk score is 68." They say: here is why the pricing is where it is, here is what we can do about it, here is what coverage looks like. The score is internal to the system. What travels to the client conversation is the explanation.
We rebuilt the output format around a decision rationale structure. The scored result now includes a short plain-language description of the primary factors driving the score, stated in terms a broker can use directly: the business class carries above-average property exposure for this region; the three-year clean claims history is a positive modifier; the revenue band places this in the middle tier for this risk class. A broker can take those sentences into a meeting without translation.
This change delayed our early-access launch by about six weeks. It was the right call. The output format a product returns is not a secondary concern. It is half the product's usefulness.
Lesson three: standard NAICS classification is not precise enough for small commercial scoring
NAICS codes are useful for broad industry classification. They are not precise enough for risk scoring across the range of small commercial businesses a broker handles. NAICS 238220 covers both plumbing and HVAC contractors. Those are meaningfully different risk profiles for BOP and GL purposes. A food service NAICS code covers restaurants, food trucks, catering operations, and commercial bakeries, each of which carries different operational and property risk characteristics.
We needed a more granular classification layer to make the scoring model work accurately across business types. We built it on top of the standard NAICS structure, adding sub-classification rules that distinguish between business types that share a standard code but present different risk profiles. That classification work took longer than expected and required ongoing refinement as we encountered business types in real applications that our initial classification scheme did not handle well.
This is a concrete example of the general lesson: the data structures that exist in the insurance industry were built for a different purpose than real-time risk scoring. Adapting them is engineering work, not just configuration work.
Lesson four: geographic risk signals are less consistent than expected
We went into year one assuming that geographic risk data at the ZIP code level would be relatively clean and consistent. FEMA flood maps, wildfire risk assessments, and state-level catastrophe model outputs are all publicly available and reasonably well-maintained. The challenge is that these data sources use different geographic units, update on different schedules, and do not always agree on how to classify borderline cases.
A ZIP code that straddles a flood zone boundary presents differently depending on which data source you query. A coastal ZIP code that is partially in a high-risk wind zone and partially in a standard zone requires a decision about how to classify the overall risk. These boundary cases are a small percentage of applications but they require explicit handling logic to avoid generating inconsistent scores for addresses that are geographically similar.
We ended up building a geographic risk resolution layer that handles the boundary cases explicitly, rather than relying on any single data source. That layer is more complex than a direct API call to a single geographic risk database, but it produces more consistent results across the full range of business locations we see.
Three things we got right from the start
Not everything in year one was a course correction. Three early decisions held up well through the first operating year.
The first was the decision to scope the model to standard small commercial applications rather than trying to cover specialty lines or large accounts from the beginning. Complex risks, unusual business types, and high-limit policies warrant a different process. Building a model that was excellent for standard BOP and GL applications was the right first scope. Expanding coverage incrementally is more tractable than trying to build universal coverage and getting mediocre results everywhere.
The second was the decision to make the carrier routing recommendation explicit and editable. The scoring engine surfaces which carriers are positioned to write a risk based on appetite signals, but the broker retains full control over which carriers they actually submit to. We did not build an automated submission routing system. We built a recommendation that a broker can use as a starting point and override based on their own knowledge of their carrier relationships. Brokers with established underwriter relationships have real information that the appetite signal layer does not fully capture. The tool should assist, not override.
The third was the decision to work with early-access brokers as genuine design partners rather than beta testers. The difference is that design partners are consulted about what the product should do, not just asked to report whether it broke. The output format change I described above came from two extended conversations with brokers in our early-access cohort who worked through exactly how they use a quote result in a client meeting. That is the kind of learning that does not come from a bug report.
What year two looks like
The funding from Tribeca Early Stage Partners gives us runway to do the work that year one identified as necessary: expanding the business class coverage in the scoring model, improving the appetite data maintenance pipeline, and growing the early-access program thoughtfully. We are not trying to be the tool for every commercial insurance use case. We are trying to be the tool that handles the standard small commercial workflow correctly and consistently for the brokers who use it.
The technical problem we are solving is not novel. Real-time risk scoring systems exist in personal lines insurance, in commercial lending, in fraud detection. The specific challenge in small commercial insurance is that the data is messier than those domains, the carrier appetite layer adds complexity that does not exist in single-carrier pricing systems, and the output needs to travel through a broker before it reaches the client. Those constraints are real. We have a clearer picture of them now than we did when we started.
