Context
Liquid's ERP platform is a large, business critical web app that had been built and maintained by a single developer for 6 to 7 years. As a contractor through Tandem Studios, I was brought in periodically in 2024 to help during busy periods, starting with small dev tasks and growing into ownership of larger features as I learned the system. In 2026, Liquid asked me to rejoin by name to help prepare the platform for a critical beta launch with a new stakeholder.
Process
Building Out Long-Requested Features
The platform had gone years without in-app notifications or a dashboard, both of which the team had wanted to build but never had the bandwidth for. For notifications, I initially proposed WebSockets, but the CTO had previously run into reliability issues implementing WebSockets with Razor Pages on ASP.NET 6, so we went with a polling approach instead. I built this as a backend service that could be used in any controller to queue notifications, paired with a frontend View Component for polling and rendering.
The dashboard used Kendo grids as the building blocks, with each grid treated as a self-contained widget. The real design problem was configuration: Liquid is used by people across very different roles, from order placement to fulfillment to invoicing, and no single user needs to see everything. I implemented a flag enum to define default widget visibility per role, paired with a per-user configuration (including widget ordering) so each person could customize their dashboard to show only what was relevant to them.
In addition to these larger platform initiatives, I also developed several standalone modules. One was a customer portal that allowed customers to track project progress and manage project-related information. Another was a time tracking system for internal staff, enabling project hours to be recorded and managed directly within the ERP. These features were implemented as complete end-to-end workflows, including database changes, backend logic, and user-facing pages.
Leading Key Features for the Stakeholder Launch
During my second engagement, the team was working against a tight deadline to support Liquid's largest stakeholder yet, which required a new payment tracking feature the platform didn't previously support. Payments needed to support multiple methods, including custom payment methods that users could define themselves in the future. The fastest path forward was a simpler, fixed schema, but that would have made it harder to support custom payment methods down the line. I designed an alternative schema that supported extensible, user-defined payment methods without anticipated future migrations, and proposed it to the CTO. He liked the approach and gave me ownership of the implementation.
Another major task was introducing proper tenancy around offices. Offices had never been cleanly modeled in the system, and a key requirement for the new stakeholder was limiting what data a user could see based on their office assignment. This touched a large portion of the platform, since office relationships were referenced throughout the majority of existing features. The work wasn't conceptually difficult, but it required care, since incomplete or inconsistent changes could easily expose data across offices that shouldn't be visible. I built the access logic as a service that could be plugged into existing pages, which kept the change centralized and minimized the amount of refactoring needed. Alongside these larger initiatives, I also built new reports, fixed UI issues, and resolved various bugs across the platform.
Outcome
In my first engagement, I worked closely with the lead developer to build two long requested features: a notification system and a dashboard that had been "coming soon" for years. When I rejoined the project, I worked largely independently to resolve outstanding issues and ship critical functionalities ahead of a major stakeholder launch, helping get the platform ready on a tight timeline.