Convex ERP System
Migrating a monolith into a modular service architecture for multi-client enterprise workflows
Due to client confidentiality, screenshots and source code cannot be shared. This case study focuses on the architecture, engineering decisions, and business outcomes.
What I did
The problem
A monolithic Buffalo backend was limiting how the platform could scale across multiple enterprise clients with different workflow needs. Tightly coupled code meant that changes in one module risked regressions in unrelated areas, and adding new client-specific workflows required modifying core application logic.
The solution
Decomposed the monolith into a modular Gin-based service architecture with standardized API contracts and clear service boundaries. Each module handles a distinct domain (workflows, users, billing, reporting) with its own routes, handlers, and data access layer. The RBAC system was redesigned from scratch to support per-client access control with optimized query patterns.
Key features
- Modular service architecture with clear domain boundaries
- Per-client RBAC with optimized authorization queries
- Standardized API contracts across all modules
- React + TypeScript frontend rebuild
Engineering decisions
Monolith coupling making cross-module changes risky
Decomposed into domain-aligned modules with explicit API contracts
Each module can be developed, tested, and deployed independently.
RBAC query performance under multi-tenant load
Redesigned the authorization layer with pre-computed role hierarchies and indexed permission lookups
Improved response times for authorization checks across the platform.
Technology stack
Impact
Lessons learned
Migrating a monolith is as much a communication problem as a technical one. Defining clear service boundaries early — and getting buy-in on those boundaries — saves enormous refactoring effort downstream.
Ready to build something exceptional?
Let's discuss how custom software can accelerate your business outcomes.