Sole developer on a legacy field-service app
Work orders for national retail chains
The engagement
This was a legacy Ruby on Rails field-service and work-order system - used by a technology-services company and operated by a facilities-management firm, supporting national retail chains. It ran on an old Rails version on a self-managed Linux server - and with a large enteprise codebase, the original developer long gone, and sparse documentation, it took ingenuity and perserverance to understand the large system we inherited. That combination is what legacy application maintenance actually deals with day to day.
What we did
- Kept the legacy app running through constant break/fix - recurring “the app is down / blank screen / users can’t log in” incidents, handled with same-day and after-hours turnaround. This is emergency production response on a standing basis.
- Performance-tuned the app for peak load - profiled the slowest part of the application and sped it up dramatically to cut peak-time strain. Faster work-order handling at peak means dispatchers get more done in the same shift.
- Developed QuickBooks integration - debugged and fixed the IIF invoice export, including tax handling on invoice items. Wiring an app to the accounting system is backend integration work.
- Ran server operations - investigated disk-space exhaustion on the production VM, set up New Relic APM at the client’s request, diagnosed Apache/DNS issues, and created backup jobs to a NAS. Self-managed boxes like this one are usually good candidates for a rehost onto managed infrastructure.
Old Rails on a hand-built server is survivable, but the incident rate is the tell. Proactive maintenance costs less than the outages it prevents.
Stack
- Ruby on Rails (2.3 / 3.0-era legacy)
- MySQL
- Self-managed Linux / Apache
- New Relic
- QuickBooks (IIF) integration