From a model to a usable prediction API.

Field note / 2026

The interface is part of the work

A notebook is a good place to explore data and train a model. Turning it into an application made me think about what a person can enter, what happens when an input is invalid, and how to present the result. Those details are part of making a model usable.

Keep the claim proportional

The model reached an R² of 0.8795 on this project’s evaluation data. I’m sharing that as a result from this experiment, not as a promise about every prediction or a claim that the model is ready for real insurance pricing. The score only makes sense alongside the data and the limits of the project.

Make the path inspectable

Using FastAPI gave me a clear place to handle inputs and return a consistent response. It also kept the model separate from the page, which made each part easier to work on. For a small project, that structure helped me learn about both modelling and delivery.

What I would improve next

If I keep developing it, I’d add examples of valid inputs, explain the evaluation data more clearly, and make errors easier to understand. Building the API was one step. A useful model also needs an interface people can follow and realistic expectations about its predictions.

This article describes a personal portfolio project, not a production insurance product.