Overview
The firm ran over 600 incident response engagements a year and tracked all of it in OneNote. The notebooks were detailed but you couldn't query across them. When leadership needed delivery metrics, financial performance, or analyst utilization, there was nothing to pull. Every answer required someone manually digging through notes.
Over two and a half years, I built the platform the firm actually ran on: intake, case management, billing visibility, and resource tracking across roughly 2,000 engagements. I started as the only engineer and eventually recruited and collaborated with a four-person team to migrate it from a monolith to a proper API-backed architecture.
What I Built
Each app targets a distinct workflow stage and shares the same underlying data infrastructure.
- Intake Form — replaced freeform notes with structured, validated incident capture. Fields cover incident classification, affected systems, ransomware group (pulled live from a threat intel API), data normalization, and incident timestamps rounded to 15-minute intervals.
- Case Management Hub — a single interface across every data source the firm uses: the primary operational PostgreSQL database, a third-party IRP API, and SentinelOne EDR. Analysts can pull case history and endpoint telemetry without switching tools.
- KPI Dashboard — tracks bookings, engagement volume, and case utilization against targets. Data comes from PostgreSQL and is composed in-app. No spreadsheets, no manual exports.
Architecture
The main architectural decision was to avoid hitting upstream SaaS APIs at query time. Node-RED handles ETL instead: Airtable syncs continuously into a queryable PostgreSQL database; NetSuite resource bookings and time entries sync into a second PostgreSQL instance. Appsmith reads from Postgres, not from Airtable or NetSuite directly. When a SaaS API goes down or rate-limits, the app keeps working.
Tech Stack
| Layer | Technology |
| Application platform | Appsmith (self-hosted) |
| Primary operational DB | PostgreSQL |
| Resource / billing DB | PostgreSQL (OpenAir schema) |
| ETL / sync | Node-RED, Prefect |
| Case / incident source | Airtable |
| Resource / billing source | Oracle NetSuite |
| EDR / endpoint telemetry | SentinelOne |
Outcome
Before this platform, the product team had no easily queryable data on anything: case volume, financial performance, analyst capacity. After: all of it was in a dashboard pulling live from the sources that actually mattered. The intake form fixed a data quality problem that had made retrospective analysis nearly impossible: dates standardized, classifications consistent, every case with a structured record from the moment it opened.
The resource utilization view went from a manual spreadsheet exercise to something any PM could pull up in thirty seconds. That's the part I'm most satisfied with: Not the technical architecture, but the fact that people actually used it to make decisions.
What Came Next
By 2025 the Appsmith monolith was showing its limits. Page load times degrading under concurrent users, JS object business logic getting hard to maintain. We recruited three additional engineers and I helped lead the migration to a proper architecture: dedicated backend APIs, a modern frontend, business logic server-side. Page load times dropped by half. Concurrent user capacity doubled.
I don't see the Appsmith phase as bad planning. Two years of real usage data meant we knew we were on the right track with what we were building, and showed us what we needed to focus on when the time came to build it right.
MI WIC Scanner 
MinuteJobs