What it changed
- An MVP shipped: the data scientists' models running as a product on AWS.
- MATLAB and Python notebooks ported into tested Python and Node.js on AWS Lambda, with PostgreSQL behind them.
- A foundation the client's own engineers took over and grew.
The situation
Insurers price agricultural risk on weather: drought, frost, rain at harvest. A start-up wanted to sell them the data and the analysis to do it better, as a marketplace for weather and agricultural data. It had data scientists, and their models worked, in MATLAB and Python notebooks. What it didn't have was a product. A notebook runs when a scientist runs it; a product runs every day, for every customer, without one.
It was one of neap.co's first serious projects.
What we did
More data science and data wrangling than app building, and a lot of business analysis first, to understand what the insurers needed and what the models produced.
- From notebooks to code. We ported the scientists' MATLAB and Python into production code, Python for the analysis and Node.js for the AWS Lambda functions around it, checking every result against the originals.
- A real back end. The data in PostgreSQL on Amazon RDS, the processing on Lambda, so the analysis ran on schedule instead of on someone's laptop.
- A front end for customers to use the data.
How it ended
We shipped the MVP, and the client was happy with it. They then hired their own engineers, who took the product on from there. That's a good ending: the point of an MVP is to prove the idea and leave a foundation others can build on.
Why it matters to you
Many companies have good data scientists and no path to production. The gap between a notebook and a product is a craft of its own: tested code, data pipelines, scheduling, and a design that customers can use. We've crossed it many times, from weather forecasts to market analysis.