Mitigately

Treating onboarding as a state machine, not a form flow

A traditional multi-step form would have collapsed under 16–20 steps with shared state, resumability, and per-step validation. I implemented a centralized step engine using React Context + Formik, where each step is an isolated validation unit within a global workflow state — index-driven, schema-validated, and type-safe throughout.

Dual-write architecture for CRM reliability

The CRM's most fundamental API — "get user by phone number" — always returned HTTP 200 regardless of whether a user existed. Standard error handling was useless. Rather than working around individual broken endpoints, I redesigned the data layer: MongoDB became the primary operational store, and the CRM was treated as a downstream sync target. An inverted lookup (query Mongo → extract CRM ID → fetch CRM record by ID) made responses deterministic.

Moving CRM sync off the request path

Initially, CRM writes were synchronous and blocking. Every onboarding step that touched the CRM added latency and a potential failure point to what should have been a fast user-facing response. I introduced an internal async queue: MongoDB writes remained immediate, while CRM sync executed in the background. This also meant CRM failures were isolated — they didn't take down user-facing operations.

Persisting step state to the backend for resumability

Users in a debt restructuring flow may need days between sessions. Storing state only in the browser would lose it. Step progress and partial form data were persisted to the backend on each transition, so on re-entry the system could reconstruct the last completed step, partial data, and navigation state exactly.