Case Study
Embedded Senior Data Scientist · Feb 2024 → Jan 2026
Raincoat LLC is a US-based insurtech building parametric insurance products for natural catastrophe risks: policies that pay out automatically when predefined climate or weather thresholds are triggered. Their products cover droughts, hurricanes, earthquakes, and other perils across emerging markets in LatAm, the Caribbean, and beyond.
When I joined in February 2024, the company had already shipped 3 perils to production: Precipitation, Hurricane Wind, and Earthquake, with Drought in early-stage development. The codebase was a monolithic block that had grown organically as the team shipped peril by peril. Coverage was concentrated in the Caribbean and Colombia.
I spent the next 2 years embedded with their data and engineering teams, contributing to climate data acquisition, new peril development, and underwriter-facing dashboards.
Raincoat had product-market fit but was hitting two ceilings.
Sales conversations kept surfacing client needs that the existing 4 perils didn't cover: drought intensity, agricultural water stress, heat-related risks. New perils took months to ship because the codebase had been built peril by peril, with each one in its own block.
The team was extending coverage from the Caribbean and Colombia toward the rest of South America and into Africa. Adding a new country was already a config change. The real issue wasn't where the data came from, but how much of it the system was processing per client.
My role wasn't to refactor the system. It was to plug into the team as a senior climate data scientist, extend coverage where I could, ship new perils alongside the existing ones, and start surfacing what a more efficient architecture could look like.
Over 2 years, I worked across data acquisition, pipeline development, dashboards, and validation. Some pieces I led, others were team-driven with my input on the climate side.
I owned the satellite and reanalysis data acquisition layer for every peril except Hurricane Wind. That meant designing the ingestion logic for CHIRPS, ERA5-Land, IMERG, Copernicus CDS, and WEkEO sources, automating their refresh cycles, and ensuring outputs were compatible with downstream pipelines.
Side benefit nobody asked for at first but ended up mattering: I generated output model data and country-level maps for the sales team, which they used in client conversations before contracts were signed. The gap between "our model says X" and "show me what that looks like for my country" was a real bottleneck. Closing it made deals close faster.
I implemented two new peril pipelines during my time.
Water Balance. Built by adapting the existing Precipitation pipeline. The peril required different climate variables and thresholds but shared the same architectural skeleton. Shipped to production with CI/CD and Docker on Kubernetes.
Heat Stress. Adapted an existing climate scientist's research script into a production-ready pipeline. The science was solid, but the script was research-grade: single-threaded, manual data inputs, no error handling. I rebuilt the data layer and model orchestration around it. The pipeline was ready at contract end but didn't reach production deployment during my tenure.
I built 3 Plotly Dash dashboards used daily by the risk and underwriting teams: Precipitation, Water Balance, and Drought. Dashboards weren't decorative. They were the interface between climate models and underwriting decisions, and a lot of the value the team delivered to clients flowed through them.
Precipitation and Drought were already in production when I joined. I maintained both throughout my 2 years (calibration checks, geographic extensions, dataset updates) and added their dashboards. Drought went from early-stage at my arrival to a stable peril in production across all targeted countries by the time I left.
The team didn't double in size. The codebase wasn't refactored. But coverage expanded measurably.
| When I joined (Feb 2024) | When I left (Jan 2026) |
|---|---|
| 3 perils in production (Precipitation, Hurricane Wind, Earthquake) + Drought early-stage | 4 perils in production (+ Water Balance), Heat Stress pipeline ready |
| Dashboards I built: 0 | Dashboards I built: 3 (Precipitation, Water Balance, Drought) |
| Caribbean + Colombia | Most of South America + 4 African countries |
| Manual sales maps on request | Country-level maps generated systematically |
What didn't change: the team kept shipping reliably on the perils that were already in production. No regression on Hurricane Wind or Earthquake during the period.
Two years of climate pipelines for parametric insurance distilled into 5 lessons: what works, what fails, and what I'd do differently next time. I wrote them up in a free PDF: 5 lessons + 12-point production readiness checklist.
If you're running a parametric insurance product or a climate risk platform, that's probably the most concrete thing I can share with you publicly.
The Climate Pipeline Reality Check 5 lessons + 12-point checklist · Free PDFI operated as a fully embedded senior data scientist within Raincoat's remote team for nearly 2 years. The engagement model was time-and-materials with weekly check-ins, shared GitHub repositories, and direct Slack communication with the technical leadership and risk team.
Work was organized project by project, with clear deliverables and direct communication between the dev and science teams. No fixed sprint cadence; the rhythm followed the work, not the calendar.
Timezone overlap (EU mornings / US East Coast / LatAm afternoons) enabled real-time collaboration without blocking either side.
I help parametric insurers and climate risk platforms ship production climate pipelines without recruiting in-house. If your team is hitting one of the ceilings Raincoat hit (adding geographies, adding perils, or modernizing a monolithic codebase), let's talk.