Industrial Scientific:
Worker Safety Platform

Industrial Scientific builds the gas detection equipment that keeps workers alive in industrial environments — refineries, chemical plants, mining operations, confined spaces. Their iNET platform is the software that connects it all: real-time alarm monitoring, fleet management, hazard tracking, compliance reporting, and equipment configuration for organizations managing hundreds of devices across multiple sites.

Project Mercury was the initiative to migrate this 15-year-old .NET application to a modern Next.js platform. The engineering team had the frontend framework in place, but the codebase was growing without foundational systems. Authentication logic was duplicated across 40+ server actions. Error handling was inconsistent — API failures were caught in some places and silently swallowed in others. Components were scattered with no shared library or documentation. In a system where inconsistency has real-world safety consequences, these weren't code quality issues. They were risk factors.

The engagement was scoped around three foundational systems: global state management, global error handling, and a component library. Design the architecture for each one, then build them.

Before writing any code, I mapped the existing system with C4 modeling — the container context showing how the Next.js application connected to the .NET REST API, AWS Cognito, the IoT data pipeline, Sentry, PowerBI, and the field equipment sending sensor data. Then I designed the information architecture mapping nine top-level sections and their sub-pages — Fleet Management, Incident Mitigation, Hazard Monitoring, Analytics, Administration, and the rest.

With the map in place, I designed each foundational system with the same organizing principle: pragmatism over perfection. Every decision optimized for the team's actual capabilities, not theoretical ideals. And every system was designed for incremental migration — nothing required a big-bang rewrite, and nothing broke existing functionality.

The three foundational systems were built using Claude Code, Claude Desktop, and Cursor — AI development tools running on the architectural foundations I'd designed first. This is the methodology in action on a client engagement, not a portfolio exercise.

The six-layer error handling system is a good example. I designed the classification matrix, the typed response interfaces, the wrapper function signatures, the DAL pattern, and the error navigation flow before opening an AI tool. When Claude Code started generating implementation code, it had explicit constraints: the error classifier is a pure function that returns a specific shape. The wrapper function accepts a specific interface. The DAL functions provide a specific ErrorContext structure. Every generated function followed the architecture because the architecture was defined before the first prompt.

Without those constraints, an AI tool generating error handling code would produce something functional but inconsistent — different error shapes in different files, different redirect patterns, different Sentry integration approaches. The architectural specification is what made the AI output coherent across a 94-story-point implementation spanning seven service modules.

The three systems shipped and the engineering team builds on them daily. Authentication boilerplate dropped from 8 lines to 1 line per server action — an 87.5% reduction across every API call in the application. The three factory function patterns give developers a clear mental model: every API call fits exactly one pattern.

The error handling system classifies every API failure, routes users to contextual error pages, and flags safety-critical operations for enhanced monitoring. The component library gives the team a single reference for available components, their TypeScript APIs, and their visual appearance — organized in a four-tier taxonomy that guides where new components belong.

Every system was designed to coexist with the existing codebase. Existing server actions continue working while new code adopts the simplified patterns incrementally. The error handling wrapper provides both the new typed response format and a backward-compatible fallback. The component library documents existing components alongside new ones. The team migrates at their own pace without breaking anything.