Custom CRM & Business Systems

OVERVIEW

Long-running work extending custom CRM and business-management software that a company depends on every day — lead management, financial workflows, HR and attendance, and field-force operations. Rather than rewriting a system the business couldn't live without, the work built modern capabilities around it: REST APIs for mobile and field teams, real-time features over SignalR, Hangfire background processing, shared authentication across old and new modules, and integrations with third-party services — all on the .NET / SQL Server stack it already ran, deployed on IIS and Windows Server.

PROBLEM

The CRM had grown with the business for years, and every department ran on it — which is exactly what made it hard to change. New needs kept arriving that the original architecture never anticipated: field staff needed to work from mobile against live data, managers wanted real-time visibility instead of end-of-day reports, finance and HR processes needed to move out of side spreadsheets into the system, and new third-party services had to plug in.

A ground-up rewrite was the obvious suggestion and the wrong one: too slow, too risky, and the business couldn't pause while it happened. The real problem was how to modernize a live system — adding capabilities at today's standards while everything already built kept working untouched.

MY ROLE

Software engineer — I designed and built the new service layer around the existing system: REST APIs consumed by the field-force mobile side, SignalR for real-time updates, Hangfire jobs for long-running and scheduled work, and authentication shared across legacy and new modules so users sign in once. I implemented the financial-workflow and HR/attendance functionality, built the third-party integrations, and handled the deployment side on IIS, Windows Server and SQL Server — working directly in and around the production schema throughout.

TECHNICAL APPROACH

CHALLENGES

The schema was already spoken for. Years of production data and code assumed the existing structures, so new features had to respect them: additive schema changes, careful migrations, and new services reading and writing the same database as the legacy modules without stepping on their behavior.

New and old had to feel like one system. New capabilities shipped as separate services against the shared database — a strangler-style approach — with authentication unified across both, so a user moving between a legacy screen and a new module never noticed a seam.

Production never paused. Deployments had to land around business hours, and background jobs that touch financial or attendance data had to be idempotent and retry-safe — a job running twice, or dying halfway, could never corrupt a workflow.

RESULT

The same core system, with a modern reach it never had: field teams work from mobile against live data through the APIs, managers see updates in real time instead of at day's end, long-running work moved off request threads into managed background jobs, and finance and HR processes that lived in spreadsheets now run inside the system with one sign-in. All of it delivered incrementally — feature by feature, with the business running at full speed the entire time and no rewrite ever needed.