TL;DR
A service request may begin with a phone call, but completing it involves much more than assigning a technician. Customer details, job locations, schedules, field updates, invoices, and employee payments all need to connect.
For established field-service businesses, modernizing the software behind these operations brings another challenge: replacing outdated technology without disrupting workflows employees already understand.
Mediusware encountered this problem while modernizing a confidential field-service management platform. The engagement involved legacy-system assessment, architecture modernization, workflow redesign, web and mobile development, and release preparation.
This field service software development case study explores how the team approached connected operations from the first customer request through technician execution, billing, and payroll while preserving the practical workflows that made the original application useful.
The existing application already linked customers, tickets, scheduling, and billing. That business knowledge was worth preserving.
Its technical foundation had become harder to change. The project records describe unsupported dependencies, tightly connected code, and recurring issues involving notifications, maps, invoices, calculations, and mobile behavior. A fix in one area could create uncertainty elsewhere.
The team needed a more maintainable foundation without making familiar tasks slower. A visual refresh alone would not resolve those dependencies.
As broader legacy modernization guidance explains, understanding existing system behavior is essential. This is general context, not a claim that the project used a particular migration pattern.
Field-service work isn't linear. Dispatchers may add a customer while creating a ticket; technicians may need prior repair history onsite; office teams handle billing after work is completed.
The documented redesign kept the customer → job site → ticket → dispatch → field work relationship central.
It also considered inline record creation, recurrence, job history, products, services, notes, photos, and checklists.
The product question was whether users could complete these tasks without retracing their steps.
One concrete UX decision concerned the moment a technician accepts an assignment.
The intended path was direct: open assigned ticket → pick up → enter working view → record work → complete.
The alternative requiring another trip through calendar screens after accepting a ticket added navigation without helping the technician perform the job.
The working view centered the current job's services, products, notes, checklists, and history keeping dispatch organized for the office and field work focused for the technician.
The final status of every subsequent ticket-state refinement still needs release verification; the documented value lies in the decision to remove an unnecessary handoff.
Recurring work is essential in many service businesses. It can also complicate a calendar when a system generates a large number of future appointments in advance.
During testing, the project team reported that prepopulating upcoming recurring tickets caused lag and crashes in the mobile experience.
The recorded design response was to keep upcoming recurring work in a separate view and introduce the relevant tickets into the active calendar when their recurrence date arrived.
The tradeoff was visibility versus performance: displaying every future occurrence burdens the application and crowds the active schedule.
The records explain the decision, but provide no post-change crash-rate measurement or confirmation of final production release.
For founders planning a technician mobile app, the larger lesson is to test workflows with realistic scheduling volumes not only with a handful of sample tickets.
Field-service platforms handle more than jobs. They contain customer contact details, service locations, pricing, collections, employee records, time-off requests, and payroll information. Different roles need different views of that data.
Early permission requirements could not be solved by simply hiding entire modules.
A technician might need enough access to create a customer or execute an assigned ticket without seeing unrelated customers, company revenue, other workers' records, or protected financial details.
Repeated client reviews refined this distinction between permission to do the job and permission to see everything. The proposed role structure included administrative, office, technician, and configurable access patterns.
OWASP's authorization guidance explains least privilege. Here, the requirement was granular access without obstructing necessary work; later permission refinements still need release verification.
Permissions were not the only data-integrity issue. More than one worker could interact with the same service ticket, making simultaneous edits a risk for notes, parts, photographs, status changes, or payment-related actions.
The documented safeguard design described a ticket lock: a second user would see a read-only view while another person was editing, then refresh after the lock cleared.
That explains the intended protection, but implementation and concurrency-test results still need confirmation.
Shared operational records need explicit conflict rules.
A job may be complete for the technician but not complete for the business. Office staff may still need to generate an invoice, collect payment, update records, and account for employee time.
The modernized product's documented scope connects ticket progress with invoicing, payment controls, attendance, paid time off, and payroll.
The payroll module includes pay structures, pay periods, runs, statuses, payslips, adjustments, and CSV export.
Job completion and financial authorization are not the same action. Technicians can finish work without permission to invoice or collect payment; office staff handle the remaining financial steps.
The project record also identifies risks around duplicate invoices, repeated charges, and edits to paid ticket history.
These were requirements for safeguards and testing; the available evidence does not justify claiming every edge case was fully resolved in production.
Similarly, CSV export supports an accounting handoff, but it is not proof of a native integration with any particular accounting platform.
Mediusware's documented contribution covered legacy assessment, architecture modernization, UX and workflow redesign, Version 2 web engineering, companion mobile development, integration-related work, and QA/release preparation.
Office teams needed broad control over scheduling, people, reports, and billing; mobile focused on assigned work, job details, time, and notifications.
This was not a product invented from zero. The legacy application supplied business rules that the new foundation needed to preserve.
The scope aligns with the wider disciplines involved in custom software development, but the original project record not a general service page is the evidence for what the team worked on here.
Modernization does not end when a build works in a test environment. Moving users and critical operations requires careful separation between development milestones and commercial availability.
The recorded release strategy called for keeping the legacy application available, testing Version 2 separately, obtaining client approval, then handling domain/user migration and mobile releases in stages.
The evidence supports an operational Version 2 web environment and companion iOS builds reaching client testing.
It does not confirm that production migration, Android release, or a complete commercial rollout had occurred. As of the documented September review, the approved iOS app was still connected to staging.
Building, validating, and migrating are separate delivery milestones.
Project Relay illustrates a field-service modernization effort spanning business-workflow analysis, technical rebuilding, web and mobile experiences, permissions, finance-related modules, and release testing.
The supported milestones are tangible: a working Version 2 environment, a mobile build available for client testing, and an evidenced payroll module.
The documentation also records product decisions shaped by direct review and mobile testing.
It does not establish measured reductions in dispatch time, maintenance expense, mobile crashes, or payroll preparation effort.
Nor does it establish a completed production migration. Those claims require independent release and measurement records.
Its value is the documented product and engineering decision-making, not a manufactured success metric.
Before choosing a development partner, ask how they will identify the behaviors users depend on that may not be written down.
Each milestone needs its own acceptance criteria, testing evidence, and owner. A partner should explain those decisions, not just list technologies.
A rebuild should preserve proven workflows while addressing architecture, usability, and release risks.
Mediusware works across product discovery, workflow design, software engineering, mobile development, and quality assurance for complex business applications.
It involves creating or modernizing applications for customer management, service tickets, scheduling, dispatch, technician activity, invoicing, and operational reporting. Depending on the business, the platform may also require mobile applications, payments, payroll, and integrations.
