ResQ CRM

Project Context#

In August 2024, I joined Kryptomind as a Software Engineer Intern. During my three months there, I worked on a few different client projects—building animated web pages using GSAP and 3D models, improving page load speeds, and helping connect crypto wallets on an NFT marketplace.

Around those tasks, ResQ CRM was my main project. On my first day, the team assigned me to this client project. It was a web platform for a US-based emergency fire and disaster recovery business that handles insurance restoration jobs. The client had already been with Kryptomind for about a year.

Before this, the business had to juggle several disconnected tools to get their daily work done—one tool for calendars and shift scheduling, another for field notes and moisture tracking, and separate chat apps to dispatch crews. They wanted ResQ CRM to bring everything together into one system: sending emergency trucks to urgent jobs (like house fires or flooded buildings), tracking vehicles live on a map, scheduling teams, and keeping track of insurance claims.

The problem was that the existing web app had a lot of issues:

• People kept getting randomly logged out in the middle of their work.
• Moving between pages was handled through global Redux state instead of normal browser URLs, so you couldn't refresh or share links.
• The dashboards loaded very slowly because everything was fetched on the client side.

After looking through the code in my first week, I suggested doing a clean rewrite from scratch in Next.js instead of trying to patch the broken parts. The project manager and the client agreed, and our designer put together a fresh Figma design for us to build.

Leading the Frontend Team#

Because I had good hands-on experience with Next.js and React, the project manager put me in charge of the frontend rewrite. I worked alongside two other developers at the company: one had just finished his internship, and the other worked mainly with WordPress.

I set up the project folder structure, chose the libraries, and helped guide how we built each page:

• Weekly Client Demos: We worked in one-week sprints. Every Friday, we got on a call with the client—along with our backend developers, mobile team, designer, and project manager—to show the features we finished that week and take notes on what to adjust.
• My Responsibilities: I handled the project setup, routing, task dashboards, user logins, and connecting the frontend to all the backend APIs.

Key Technical Challenges & What I Built#

Here is a walkthrough of the working production application I implemented from the Figma prototype, featuring real-time disaster incident management, lead tracking, task scheduling, and live field response dispatch:

1. Modernizing Auth, SSR & Route Architecture

While building the core dispatch views and task dashboards, I addressed the architectural flaws that had slowed down the legacy app:

• NextAuth.js Authentication: Implemented NextAuth.js to handle secure session persistence and role-based route protection, resolving the random logout issues from the previous system.
• Next.js Server-Side Rendering (SSR): Switched heavy data tables from client-side data fetching to Next.js server-side rendering, cutting initial dashboard load times significantly.
• Eliminating Redux Route Hacks: The old codebase managed screen transitions and navigation states by manually updating Redux stores. I proposed replacing this with native Next.js dynamic routing ([id]) and URL search params so URLs were shareable, bookmarkable, and fast. The project manager asked me to discuss this with our Frontend Team Lead; I walked him through the architectural benefits, got his approval, and completed the migration ahead of the Friday client review.

2. Live Field Crew Tracking on the Map with Cloud Firestore

Dispatchers needed to see active emergency response vehicles and field teams moving live on a map so they could quickly assign the closest available crew to an urgent disaster site.

Senior engineers assigned the map and real-time telemetry integration to me:

• Cloud Firestore over Realtime Database: When evaluating how to sync coordinates, I connected Cloud Firestore instead of Firebase Realtime Database. Firestore was significantly more cost-effective for our scale and query patterns, avoiding the high continuous bandwidth costs of Realtime Database while still providing live document snapshots (onSnapshot) to stream coordinate updates directly into the dashboard.
• Client Throttling & Marker Clustering: High-frequency GPS pings from mobile devices can easily cause browser repaints to stutter. I throttled coordinate updates on the client and added marker clustering, ensuring the map stayed smooth and readable even when multiple response teams converged on an incident area.

3. Handling Mid-Sprint Backend API Shifts Under Deadline

A few days before an important Friday client demo, the backend team made several schema adjustments to the endpoints our dashboard relied on. This temporarily broke our job assignment workflows.

Instead of waiting for the next sprint, I traced the breaking changes across our API layer, remapped the request and response models, and updated the state handlers across the dispatch views before Friday morning. The demo went smoothly, and the client was able to see live vehicle movements and test the full dispatch flow without any hiccups.

System Architecture#

Dispatchers (Next.js Web Dashboard)     Field Response Crews (Mobile GPS Stream)
               │                                      │
               ▼                                      ▼
┌─────────────────────────────┐        ┌─────────────────────────────┐
│ Next.js App Router Client   │        │ Background Coordinate Pings │
│ ├── NextAuth.js Sessions    │        └──────────────┬──────────────┘
│ ├── Dynamic URL Routing     │                       │
│ └── Server-Side Rendering   │                       │ Post lat/lng updates
└──────────────┬──────────────┘                       ▼
               │ Fetch & mutate jobs   ┌─────────────────────────────┐
               ▼                       │ Firebase Cloud Firestore    │
┌─────────────────────────────┐        └──────────────┬──────────────┘
│ REST API (Backend Services) │                       │
└──────────────┬──────────────┘                       │ Real-time snapshot stream
               │                                      │
               └──────────────────┬───────────────────┘
                                  ▼
┌────────────────────────────────────────────────────────────────────┐
│ Clustered Interactive Map (Throttled GPS Markers & Incident Pins)  │
└────────────────────────────────────────────────────────────────────┘

Outcomes & Handover#

• Successful Sprint Demos: The rewrite resolved the longstanding session and authentication bugs from the legacy app, giving the client a responsive, reliable dashboard with live fleet visibility during our weekly Friday demos.
• On-Going Development: ResQ CRM was a large enterprise platform with a multi-phase roadmap. When my three-month internship concluded in November 2024, the core Next.js architecture, NextAuth.js sessions, task dashboards, and live Cloud Firestore telemetry were fully in place and operational, while remaining roadmap features continued in active development with the permanent engineering team.
• Full-Time Job Offer: Based on the work I did leading the ResQ CRM rewrite and helping out across other client projects at the company, Kryptomind offered me a permanent, full-time Software Engineer position at the end of my internship. I had to turn it down so I could finish my final year of software engineering at FAST-NUCES, but it was great recognition of the impact I made.

What I Learned#

• Know when to rewrite vs. patch: When a codebase suffers from fundamental architectural flaws like broken session state, continually patching bugs often costs more time than setting up a clean foundation.
• Rely on native web standards over state hacks: Using standard URL search params and dynamic routes is cleaner, faster, and more maintainable than routing through global state managers like Redux.
• Evaluate cloud service costs early: Choosing Cloud Firestore over Firebase Realtime Database saved operational costs while still giving us real-time document listeners to power our live dispatch map.
• Take ownership during integration: Backend contracts often shift under tight deadlines. Tracing changes early and adapting the frontend quickly prevents surprise blockers during client reviews.