Turning a Legacy Showroom into a 24/7 Global Car Marketplace & Auction Engine

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 buys used vehicles in its home market and ships them to buyers around the world, across the Caribbean, Africa, Europe, Asia, South America, and Oceania. Its customers rarely meet a salesperson in person. They find a car on the website, judge it from photographs and specifications, and commit to buying it from thousands of kilometers away. For a business run that way, the website is not a marketing channel sitting beside the real work. It is the showroom, the sales desk, and, through a companion online auction, the trading floor. Exact financials are withheld for confidentiality.

THE CHALLENGE

The platform that had carried the business to this point was written in Ruby and had grown with it over the years. It worked, but it was increasingly difficult to extend, and the client wanted a new foundation: a modern .NET backend and a Next.js frontend, hosting on cloud infrastructure with a content delivery network for buyers on the other side of the world, load spread across several servers, and a current version of its database.

A rebuild like that usually starts from a specification. Here there was none. The old system carried no detailed description of its own business logic, so the knowledge of how stock, orders, and customer actions were supposed to behave lived only inside the code. Replacing a storefront is the easy half of a project like this. Replacing behavior that nobody has written down, without losing any of it, is the half that decides whether the new system can be trusted on its first day.

The new platform also had to do more than the old one. The client wanted buyers to be able to purchase a car without going through a salesperson, wanted stock visible across its group of companies, and wanted the whole thing checked for web vulnerabilities before launch. Alongside the storefront sat a second system with a very different shape, an online auction used by two kinds of people at once: staff running every stage of a bidding session, and buyers competing inside it.

PROJECT OBJECTIVE

The client wanted its existing storefront replaced without losing a single behavior the business depended on, and wanted the new platform to open up capabilities the old one never had: direct purchase, group wide stock visibility, six languages, and a security review. The companion auction system had to run on the same foundation, so that both channels could grow together instead of apart.

APPROACH AND METHODOLOGY

Treating the legacy code as the specification

With no written description of the old system, the team made its source code the single source of truth. The legacy Ruby code was read closely and turned into basic design documents, so that the new build had something concrete to be written and tested against. AI assisted analysis helped trace logic through the old codebase faster, and what it surfaced fed directly into those design documents. It is the same discipline behind our broader legacy modernization work: recover what the system actually does before deciding how the new one should do it.

Giving the new system a spine that does not depend on any framework

Rather than writing the backend as one tightly woven application, the team organized it into four clear layers. A Domain layer holds the core business logic and has no dependency on any framework, including the data access library. An Application layer holds the use cases and business orchestration. An Infrastructure layer handles data access and external services, and a WebApi layer handles endpoints and HTTP. Dependencies flow in one direction, from the WebApi layer through the Application layer to the Domain, with Infrastructure plugging in from the other side. The repository and unit of work patterns keep data access consistent, and a generic use case base class lets common behavior be written once and reused.

The reason for that discipline is practical. Business rules recovered from an undocumented system are precious, and they should not be entangled with whichever library happens to be fashionable this year. Keeping them in a layer of their own means they can be tested in isolation and survive future changes to everything around them.

Building delivery and security into the plan, not onto the end of it

Static assets were placed on S3 behind a content delivery network so that pages and photographs load quickly for buyers wherever they are, traffic was distributed across several servers, and the database was upgraded to MySQL 8. Security testing, with a written report, was part of the delivery, which mattered for a platform that takes real orders and real payments from the public internet.

Keeping design, test, and infrastructure documents in step

Basic design documents, test cases, and infrastructure diagrams were maintained as shared references throughout, so that what had been recovered from the old system, what was being built, and what was being tested all pointed at the same picture.

TEAM SCALE

Across the storefront and the auction platform, VNEXT worked with a dedicated team of between eight and sixteen engineers at different stages, sized to the work in front of it. The mix reflects a project where reading old code, building new code, and proving that the two behave alike all carried equal weight.

• Project managers and a bridge communicator: kept scope, schedule, and day to day requirements aligned between the client and the delivery team
• A designer: shaped the storefront and back office interfaces so that dense information, such as vehicle specifications and auction data, stays readable
• Backend engineers: built the .NET Core services and the layered architecture that both the storefront and the auction platform share
• Frontend engineers: built the Next.js storefront and the staff facing back office
• An engineer fluent in the legacy language: read the original Ruby code so that its behavior could be captured in design documents
• Testers: a substantial group on the team, verifying the new system against the behavior recovered from the old one
• A DevOps engineer: owned the cloud environment, content delivery, and deployment

THE SOLUTION AND TECHNOLOGY STACK

What the client ended up with is two connected sales channels on one engineering foundation: a storefront for buyers who know exactly what they want, and an auction for buyers who want to compete for it.

The export storefront

• Stock list and search: lets buyers browse and filter the full range of available vehicles
• Basket, Request Now, and Buy Now: lets a buyer request a vehicle or purchase one straight away, without going through a salesperson
• Purchase history, favorites, and wish list: keeps a buyer's past orders and shortlisted vehicles in one place
• Shipping and payment: carries a purchase from the basket through to delivery arrangements and payment inside the same flow
• Group stock visibility: shows stock across the exporter's group companies and between them, so a buyer sees what is genuinely available
• Six languages and regions: serves buyers in their own language and with region specific content
• Multilingual content management: gives staff an editor with a live side by side preview for writing and translating news and page content

The online auction

• Auction and bidding: lets registered buyers search cars and motorcycles by make, model, year, mileage, auction location, and starting price, add vehicles to a personal list, follow auction details, and place bids
• Full session control for staff: covers editing vehicle data, dividing vehicles into lots, tracking vehicle status in the yard, processing OCR requests, controlling bid limits, and recording final results
• Bid limit reminders and deposit rules: keeps bidding within each buyer's limit and in line with the auction's deposit requirements
• Direct messaging and negotiation: lets staff talk to buyers one to one and manage negotiations inside the system, alongside an integration with Microsoft Teams
• Buyer account pages and purchase history: gives each buyer a personal page for their activity and past purchases

Technology Stack

Both channels sit within VNEXT's wider web application development practice, which covers marketplaces, portals, and back office systems built to carry real transactions.

THE RESULTS

A system whose behavior once existed only in code now exists in code, design documents, and test cases, and it serves buyers in a way the old storefront could not.

• Buyers act without waiting on a salesperson: Request Now and Buy Now put the decision in the buyer's hands, whatever the time zone, which matters when most customers are an ocean away from the people who could otherwise take their order
• One honest picture of available stock: stock across the group's companies is visible in one place rather than checked company by company
• A written baseline where there was none: the logic of the old system is now captured in design documents and test cases, so the next change begins from a reference rather than from reading old code
• Security checked before it mattered: the platform was tested for web vulnerabilities and reported on before it went live to the public internet
• Two channels, one foundation: the storefront and the auction share the same layered architecture, so improvements and fixes in one carry naturally to the other

For an exporter whose customers never visit the showroom, that foundation is the difference between a website that merely lists cars and one that can run the business. With the logic recovered, documented, and kept apart from the technology around it, the client can add the next market, the next payment option, or the next sales channel without having to rediscover how the last one worked.