Building a digital repair order app for automotive dealers

PROJECT OVERVIEW

ABOUT THE CLIENT

This case study is based on a real VNEXT project. The client's identity and certain project details have been anonymized or generalized for confidentiality purposes.

Our client for this engagement is a leading global automotive and motorcycle manufacturer, reached through one of its long standing global IT solutions partners. The work supported the manufacturer's authorized dealer network in Vietnam, where dealership staff needed a faster way to look up customer records and open a repair job. Exact contractual details are withheld for confidentiality.

THE CHALLENGE

Every small clarification with the client traditionally required an email or a written confirmation before work could continue, a safe habit that turned slow whenever a dealer facing feature needed a same day answer. On top of that, requirements kept shifting as the client's own thinking about the product evolved, leaving no single settled specification to build against.

A deeper technical challenge only surfaced once development moved closer to the client's real infrastructure. The backend had been designed as a set of microservices connected through Redis as a lightweight bridge between the API gateway and individual services. Once the application reached the client's own environment, a load balancer already in place there caused requests to be processed more than once, a mismatch that had not shown up inside the team's own development environment.

PROJECT OBJECTIVE

The client needed a working application quickly, one that let dealership staff search customer information and open a repair job card in a fraction of the time a manual process took, without letting a still evolving specification stall delivery or letting an architecture built around assumptions cause instability once it reached production infrastructure.

APPROACH AND METHODOLOGY

Keeping development moving while confirmations are pending

Rather than pausing work every time a clarification was needed, the team adopted a sprint planning routine that surfaced likely open questions before a sprint began, sent them to the client for confirmation, and let development continue in parallel instead of sitting idle while waiting for a reply.

Protecting delivery from a moving specification

When new requirements arrived mid sprint, the team held to the scope already committed for that sprint, logged the new request by priority, and scheduled it into the next planning cycle rather than letting it disrupt work already underway.

Building one shared specification, not several

To close early gaps in API and design documentation, the team standardized on shared templates for writing specs and settled on a single reference version of each specification used by both development and QC, so no one was building against a different understanding of the same feature.

Adapting the architecture to the client's real infrastructure

After tracing the duplicate request issue to the client's load balancer sitting in front of the Redis based gateway to service connection, the team changed the protocol connecting the gateway to its services to match how the client's infrastructure actually behaved, a fix that came directly out of testing against the real environment rather than assumptions made during initial design.

TEAM SCALE

Project records for this engagement do not include a specific headcount, though delivery drew on a cross functional group spanning specification, development, and quality control.

• Backend and frontend developers: built and connected the customer lookup and repair job card features across the application's Node.js based services
• QC: verified features against a specification shared with development, covering integration, system, and unit testing
• BrSE / PM: coordinated specification confirmation with the client and ran sprint planning to keep delivery on schedule despite shifting requirements

THE SOLUTION AND TECHNOLOGY STACK

The application gives dealership staff a direct path from finding a customer to opening a repair job, replacing steps that previously depended on manual lookup and paper style job cards.

What was built

• Customer lookup: lets dealership staff quickly search existing customer records instead of checking paper files or separate systems by hand
• Digital repair job card: creates a repair job card directly from a customer's record, replacing a manual, paper style process
• Microservice backend with a gateway bridge: backend services connected through Redis as a lightweight bridge between the API gateway and individual services, later adjusted to work correctly behind the client's load balancer

Technology Stack

THE RESULTS

A slower, manual way of finding a customer and opening a repair job became a direct, in app flow for dealership staff.

• Faster repair job creation: dealership staff look up a customer and open a repair job card directly in the app, replacing a slower, manual process
• Delivery that held up under a moving specification: sprint planning and clear prioritization kept committed work on schedule even as the client's own requirements kept evolving
• An architecture corrected before it caused a bigger problem: the gateway to service connection was fixed to work properly behind the client's load balancer, preventing duplicate request processing once the system reached production infrastructure
• One specification standard across teams: development and QC worked from the same reference documents, closing a gap that had caused inconsistent understanding earlier in the engagement

A digital job card that shaves minutes off a single repair request looks like a small change on paper, but multiplied across an entire dealer network, it is exactly the kind of improvement that adds up.