ProcECS Engine

Project Background

During my internship at Effective Computer Solutions, I was tasked with building a new web-based technician-management tool. Instead, I pitched something bigger: pull every one of the company's scattered internal tools, spread across different tech stacks and servers with no shared branding, into a single portal with one consistent interface. Sales couldn't find what they needed. Marketing had nowhere central to work from. A unified platform would fix both.

Six months later, the company sold its first subscription. It quickly became the company's flagship product.

My role centered on the foundation: establishing the project, building the core components used throughout the product, enforcing the design system, and optimizing server load and action performance. As the team grew, I also held the line on code quality, pushing back on inconsistent UI, loose typing, and missing error handling before they became structural problems. This was before AI tooling could meaningfully help with code review, so it meant a lot of manual attention to detail across every pull request.

The frontend and backend run on Next.js and TypeScript, with Express microservices behind them handling the ORM layer and database connections to MSSQL and SAP HANA. Seq handles structured logging, giving the team searchable logs across every service. Each client runs their own deployment on their own servers, which solves data security concerns outright but introduced real challenges around rolling out updates across a growing number of isolated environments.

Today the platform includes a warehouse manager, price quoting system, technician manager, business metric reporting, and a movable, resizable dashboard, among a dozen other tools. Each organization gets a workspace shaped to how they actually operate.

Technical Highlights

Multi-tenancy was the first real architectural challenge. We built a hybrid system that pairs role-based access control with fine-grained attribute-based permissions. Companies control access per user by resource and by service, so two people in the same organization can see completely different tools and data. Every route and UI element respects this layer.

The generic table component sits at the center of nearly every view. Built on TanStack Table, it accepts column definitions, data sources, and action handlers rather than requiring custom tables per module. Server-side pagination, multi-column sorting, inline editing, row-level actions: all configuration, no per-feature code.

The platform reads from MSSQL for legacy data and writes to SAP HANA for reporting and analytics. We built a microservice ORM that translates a single query definition into dialect-specific SQL for each target, keeping application code database-agnostic. Credit to our team lead, Kenny Ponton, for his work on this service. Without it, this project would have been significantly more painful.

The dashboard was built from scratch. Users can drag and drop widgets, resize them freely, and organize them across different categories. What a user sees depends on their permissions, so each role gets a dashboard tuned to what matters to them.