Internal Operations Platform

Overview

What was built and why it matters.

Built at Lyor in the Senior Software Engineer role using React, Node.js, Express.js, MongoDB, Socket.IO, AWS, and Docker.

Replace fragmented operational processes with a dependable system that could coordinate location-aware verification, recurring work, role-specific access, and real-time updates without allowing frontend complexity or database latency to grow with the product.

Engineering approach

• Structured the React application around domain-focused modules, reusable UI components, clear routing boundaries, and predictable API integration patterns.
• Built REST APIs and workflow services for attendance, GPS geofencing, QR verification, role-based access control, recurring tasks, and notification delivery.
• Designed role-aware screens and validation states so employees, managers, and administrators could act on the same operational data without exposing inappropriate controls.
• Used Socket.IO for targeted real-time updates while keeping persisted REST responses as the source of durable application state.
• Profiled route changes, state subscriptions, and component rendering, then removed unnecessary work from the navigation path.
• Reviewed MongoDB query behaviour and replaced affected collection scans with indexed lookups aligned to frequent access patterns.

Challenge

The system problem.

The platform combined identity, location, verification, recurring work, notifications, and live state in one product. The engineering challenge was not only adding features, but preserving understandable interfaces, consistent permissions, predictable data flow, and responsive performance as workflows became interconnected.

Constraints

Known boundaries and deliberately unclaimed details.

• Operational flows had to remain understandable for users with different responsibilities, making authorization, data visibility, and role-specific actions first-class product concerns rather than backend-only checks.
• Location and QR-based verification required defensive validation, duplicate-action protection, explicit error states, and recovery paths for stale client data or intermittent connectivity.
• Real-time events needed to update relevant views quickly without creating conflicting state, repeated notifications, or unnecessary React render cycles.
• Performance improvements had to be introduced without destabilising business-critical workflows already used across multiple departments.

Role and ownership

Individual contribution.

• Worked as the Senior Software Engineer responsible for translating operational requirements into product architecture and executable delivery plans.
• Owned backend APIs, validation rules, workflow automation, data access, and real-time integration for the listed operational domains.
• Designed and improved the React application structure, state boundaries, routing behaviour, API integration layer, and reusable component patterns.
• Diagnosed production-facing performance bottlenecks through measurement rather than assumption, then delivered targeted rendering and indexing fixes.
• Supported containerised delivery, deployment, debugging, and production follow-through on AWS.

Contribution summary

• Owned feature delivery across frontend workflows, backend APIs, data access, real-time events, deployment support, and production troubleshooting.
• Defined reusable frontend boundaries and API contracts for operational modules that shared identity, permissions, and status data.
• Implemented workflow automation across attendance, geofencing, QR verification, recurring tasks, and multi-channel notifications.
• Led the measured frontend and database performance improvements reported in this case study.
• Collaborated with business stakeholders and users across seven departments to translate operational rules into maintainable product behaviour.

System architecture

A profile-backed view, not an invented topology.

• A domain-oriented React client presents role-aware workflows through reusable components, route-level modules, and a shared API layer with consistent loading, success, empty, and error states.
• Node.js and Express.js expose REST endpoints that validate input, enforce authentication and RBAC, apply workflow rules, and coordinate persistence through MongoDB.
• MongoDB stores operational records, verification events, recurring-task state, and access-related data; indexes support frequent filtered lookups and latency-sensitive paths.
• Socket.IO publishes scoped operational events so affected users receive timely updates without requiring full-page refreshes or aggressive polling.
• Notification adapters isolate WhatsApp and email delivery from core workflow logic, while Docker and AWS provide repeatable application packaging and deployment support.

Key engineering decisions

Choices supported by the supplied work.

• Organise frontend and API code by business domain so related components, routes, validation, and workflow rules remain easier to change together.
• Keep authorization checks in backend services while also reflecting permissions clearly in the interface to reduce confusing or invalid user actions.
• Use explicit real-time event contracts for operational changes instead of coupling the UI directly to database-level events.
• Optimise measured state, rendering, routing, and query bottlenecks rather than applying broad rewrites without evidence.
• Separate notification delivery from the core transaction path so communication failures do not obscure the underlying workflow state.

Performance and reliability

What changed measurably.

• Reduced route-transition time from approximately 650 milliseconds to 45 milliseconds by simplifying the navigation path and removing unnecessary frontend work.
• Reduced page-load render passes from four to one for the optimised flow.
• Reduced average latency for affected MongoDB queries from approximately 120 milliseconds to 8 milliseconds by replacing collection scans with indexed lookups.
• Improved maintainability by giving shared workflows consistent component, API, permission, and error-handling patterns.

Technologies

The verified stack and focus areas.

Outcome

The result without inflated claims.

A production platform serving more than 100 employees across seven departments, with faster navigation, lower database latency, clearer role-aware workflows, and a maintainable foundation for additional operational modules.

Lessons and future improvements

What the evidence suggests—and what still needs verified content.

Lessons

• Profiling at the route, render, and query levels produced more defensible gains than undirected optimisation or premature rewrites.
• Permissions are most effective when backend enforcement and frontend affordances communicate the same operational rules.
• Real-time behaviour remains easier to reason about when event contracts, persisted state, and user-visible recovery paths are designed together.

Future improvements

• Add structured logs, request correlation, operational metrics, and distributed tracing so failures can be followed from the user action through API, database, event, and notification boundaries.
• Move notification delivery behind a durable queue with retry policies, idempotency keys, dead-letter handling, and an operator-visible delivery history.
• Introduce automated accessibility checks, route-level performance budgets, and browser-based regression tests for the highest-value employee workflows.
• Expand audit timelines and administrative diagnostics so authorised users can understand who changed a workflow, what changed, and how the system responded.
• Use feature flags and staged rollouts for high-impact workflow changes to reduce deployment risk across departments with different operating patterns.