Instant Risk Coverage - insurance data & reporting pipelines

The role

Instant Risk Coverage sells insurance through an e-commerce-style platform built on Medusa, so the business runs on two kinds of data at once: order and product data from the storefront, and policy, premium, and commission data from the insurance side. As a Technology Operations Developer over the Summer 2026 term, I worked across that data and reporting layer - keeping the existing analytics pipelines healthy, standing up reporting for a brand-new insurance platform, and building operational tooling for the parts of policy administration that were still manual or slow.

Most of the work sat at the seam between raw operational systems and the numbers people actually act on: finance teams reconciling premium, carriers receiving monthly statements, and operators processing cancellations. The recurring theme was turning messy, multi-source records into trustworthy, repeatable outputs.

What I worked on

I owned several pipelines end to end rather than a single feature. On the analytics side I extended the existing warehouse; on the insurance side I built new reporting from the ground up; and on the operations side I replaced a slow manual process with a validated toolkit. Across all of it the priority was correctness under real-world edge cases, because these outputs go to carriers and finance rather than to a dashboard nobody checks.

Reporting pipelines

I enhanced more than ten Mage AI ETL pipelines that transform Medusa e-commerce data through a PostgreSQL staging layer into data mart tables, which power the company's Metabase reporting. Keeping those healthy meant working inside an existing warehouse pattern - staging first, then modelled marts - rather than pulling numbers straight from production.

I then built the end-to-end reporting pipeline for a brand-new insurance platform. That meant landing an internal pricing service into a new staging layer and data mart, then calculating premium, commission, and net figures at separate insurer and broker rates - and generating 256 monthly Excel statements to send out to carriers. Because insurers and brokers settle at different rates, the calculation logic had to be explicit and auditable, not a single blended number.

To retire an older process, I automated monthly policy-level premium reporting. The report joins order, line-item, customer, entity, SKU, and payment data in SQL, with Python handling validation and formatting on top. Before cutover, I reconciled the automated output against the legacy system so the switch could happen with confidence that the new numbers matched the ones the business already trusted.

Policy-cancellation toolkit

Separately, I built a Node.js and MongoDB toolkit for processing parent-child policy cancellations. Cancellations are not a single row - a parent policy can have dependent child policies, and getting one wrong has real financial consequences - so the toolkit was built defensively: rollback snapshots so a bad run can be undone, explicit edge-case validation, and CSV-to-JSON conversion to bridge the input formats the team worked with. Automating what had been a manual, error-prone process cut processing time by over 90%.

Key decisions

• Stage first, then model. Both the e-commerce and insurance pipelines land raw data into a PostgreSQL staging layer before building data mart tables, so reporting reads from stable, modelled tables instead of live operational systems.
• Make rate logic explicit. Premium, commission, and net were calculated at separate insurer and broker rates rather than a blended figure, so the 256 monthly statements are auditable line by line - the kind of correctness carriers and finance actually need.
• Reconcile before cutover. The automated premium report was checked against the legacy system before switching over, so replacing a trusted process never meant trusting unverified numbers.
• Build cancellations to be reversible. Rollback snapshots and edge-case validation came first, because a parent-child cancellation toolkit that is fast but wrong is worse than the manual process it replaces.

Impact

The term left the business with pipelines and tooling it can keep running: 10+ enhanced Mage AI ETL pipelines feeding Metabase, a new insurance-platform reporting pipeline generating 256 monthly carrier statements at correct insurer and broker rates, an automated and reconciled monthly premium report ready to replace the legacy system, and a cancellation toolkit that cut a manual process's time by over 90% while making it safer to run.

What I would do differently

I would invest earlier in automated data-quality checks between the staging and mart layers. Much of the manual reconciliation work exists because problems surface at the report, not at ingestion; contract-style tests on the staging tables would catch bad or missing data before it reaches a carrier statement.

I would also generalize the rate-calculation logic into a small, well-tested module rather than pipeline-specific code. With insurer and broker rates already diverging, a single shared calculation layer would make new products and new carriers cheaper to onboard and easier to audit as the insurance platform grows.