A field-service and dispatch platform, one engineer, since 2009

What it does

When a contractor arrives at a cell site, an operator opens a ticket. The platform associates the site’s alarms and pulls in everything the crew needs automatically: directions, access instructions, landlord details, and the site’s history of issues.

Field technicians work from a mobile interface at the tower itself. They attach photos, record the parts they installed, and document the work performed, often from remote sites.

Behind that, the back office runs on the same system:

• Live dispatch map showing where crews are working right now, so the closest available team can be sent to an emergency call.
• Warehouse and asset tracking, integrated with inventory to find the nearest location holding the parts a job needs.
• Workload planning and billing workflows.
• Change orders, invoices and expenses, including an importer for invoice files.
• Structured site inspections (HVAC and site condition, readings, test results) and warranty tracking.
• Reporting used by engineering and management: KPI reports, summaries and scorecards, with export.
• Vendor portal with vendor-scoped security, so subcontractors see and update only their own work.
• Role-based access, activity history and workflow automation throughout, with email and Slack notifications.

Getting data in

Much of the work arrives as spreadsheets: carrier updates, work-in-progress lists, scorecards, parts locations. Rather than retyping them, the platform has around two dozen import parsers that read these Excel and CSV files straight into the database, plus an import from the ServiceMax field-service system. It’s the unglamorous side of the system.

Being the whole team

There’s no separate ops group, QA team or release manager. I own the backend services (C# and SQL Server), the operations UI, the mobile experience, every environment, and every release and deployment. That shapes how the system is built: it has to be understandable by one person, deployable by one person, and safe for one person to change on a Friday.

Replacing the front end without stopping the business

A system that runs a business every day can’t stop for a rewrite. The original application, WorkOrders, is ASP.NET Web Forms on SQL Server: over 70 pages, around 190 tables and views, and tens of thousands of lines of C#. Rewriting all of that at once would have meant years of risk for no visible benefit.

So the modernization goes from the inside out, one layer at a time:

• An API inside the running app. I added an ASP.NET Web API to the live Web Forms application: about 150 JSON endpoints secured with JWTs and refresh tokens, sharing the same database and business logic the old pages use. Nothing had to be migrated to start.
• A new front end on that API. maint-mobile is a rewrite of the user interface in React 19 and TypeScript, with Redux Toolkit and RTK Query. It’s an installable progressive web app that works on a phone at the base of a tower as well as on a desk.
• Passkey sign-in. Field techs can sign in with their phone’s biometrics through WebAuthn passkeys, implemented on the .NET Framework side, instead of typing a password on a phone.
• Retire the old UI, keep the old API. Both front ends run side by side against one database while users move over. The legacy pages are about to be switched off; the API they grew stays in service.

Maps have been through the same kind of gradual replacement, from MapQuest to Google Maps to Leaflet, with marker clustering so a region full of sites and crews stays readable.

Choosing the platform for the job

The first companion mobile app was built in Flutter and shipped to both the Apple App Store and Google Play. As requirements evolved, I rebuilt the mobile experience as a responsive React PWA. For this team a PWA was simpler to maintain and deploy, and it gave field techs a streamlined experience without store releases.

I’ve made the opposite call too. My medication app Nexpill started as a PWA and moved to Flutter, because web reminders couldn’t be relied on to fire on time. Neither choice is right in general. The requirement decides.

Results

• Still in daily production, supporting thousands of maintenance operations across the region.
• A new React/TypeScript front end built on the live system’s own API, with the legacy Web Forms UI retiring and no big-bang cutover.
• A mobile workflow used on-site by technicians at remote tower locations.

If you have a system like this

Plenty of businesses run on a web app someone built years ago, often in Web Forms or older .NET, that nobody wants to touch. Taking over a system like that, putting an API in front of it, and replacing it piece by piece while the business keeps running is exactly the work I’ve been doing here.