From a simple listings site to 40,000 vehicles: five years of scaling a web application
Five years ago we started building what looked like a fairly straightforward project for CHANGECARS: a South African vehicle listings website where dealers could display their stock and buyers could send enquiries. It started with tens of dealers and a few thousand vehicles. Today that same platform carries around 40,000 vehicles from roughly 1,000 dealers, serves 3,000 to 4,000 users every day, generates a steady stream of leads for dealers, and pulls stock in through seven automated feeds that run multiple times a day, alongside a growing list of integrations. It has never stopped growing.
This is the story of how that growth played out from the inside. We want to be honest about what it actually takes to keep a web application fast, stable and trustworthy while the business behind it is scaling quickly, because most of the lessons we learned were not about writing clever code. They were about anticipating where the pressure would come from next, building in the safety nets before they were needed, and keeping our client informed enough that they could keep investing in growth with confidence. If you are a business owner or decision-maker with a platform that is starting to feel the strain, we hope this gives you a realistic picture of what lies ahead and how to prepare for it.
Early simplicity and the first growing pains
When the project began, everyone involved, ourselves included, assumed the first phase would be the big piece of work, followed by a handful of small enhancements if that. The platform ran comfortably on a single dedicated server, the search covered the basics a buyer needs when looking for a car, and the volume of dealers and stock was modest enough that performance was simply never a conversation.
That changed as our client began investing more heavily in social media, digital marketing and advertising. The spend worked, which is exactly what you want, but it meant that traffic and engagement climbed month after month. There was no single dramatic outage that announced the problem. Instead, we started to notice the server producing errors and the web application failing intermittently. When we dug into the logs, the errors were clearly server and resource related, and when we put those logs alongside Google Analytics, the picture became obvious: the errors were rising in step with the growth in traffic. The server was no longer able to keep up with the demand the marketing was generating.
This is one of the most common and least visible ways a platform reaches its limits. It rarely fails all at once. It degrades quietly, with occasional errors, slower pages and the odd failed request, and if nobody is correlating the technical signals with the business signals, those early warnings are easy to dismiss as noise. For a lead-generation business, though, every failed page load is a potential enquiry that never reaches a dealer.
Infrastructure and data maturity
Splitting the application from the database
By around year three, with at least 30,000 vehicles and 600 dealers on the platform and traffic climbing steeply, it was clear the dedicated server had reached its ceiling, and we moved the platform to a private VPS environment. The hardest part of that decision was not the migration itself but working out how to structure the environments and how to divide the processing power between them. We did not want a quick fix that would leave us facing another upgrade in a year or two; we wanted an architecture that would remain robust for years.
It is worth saying that this change was a natural evolution rather than a sign that something had been planned badly. As our Co-Founder and CEO, Angelo Zanetti, puts it: "We planned correctly for scale in terms of data and features, building on a solid framework from the start, but with huge growth we needed to change the infrastructure. That was fine, because a start-up can't afford top-level infrastructure at the outset. It was a natural evolution, and it was handled well." Matching infrastructure spend to the stage of the business, while keeping the application itself ready to move, is often the most sensible way to grow.
Given the complexity of the application, the sheer volume of data, the number of queries running at any moment and the automated feeds constantly writing new stock into the system, we decided to separate the web application and the database onto their own dedicated servers. That separation means the application can serve users without competing for resources with heavy database work, each layer can be tuned and scaled independently, and a spike in one area is far less likely to bring down the other.
Redis caching and a dramatic improvement in speed
Alongside the infrastructure split, we introduced Redis to cache the data and queries that were being requested over and over again. On a listings platform, a large share of what users ask for is the same, so we focused on three areas: filter counts, search results and dealer pages. Rather than asking the database to recalculate those answers thousands of times a day, Redis holds them in memory and serves them almost instantly. The result was a tremendous improvement in the speed of the web application and a drop in server CPU load of at least 20 to 30% on average, which took significant pressure off the database and gave the whole platform more headroom to absorb future growth.
Monitoring, reporting and a DevOps partner
Moving to a more sophisticated infrastructure also meant we needed far better visibility into how it was behaving. We added strong monitoring and reporting tools, run by our DevOps partner, so that server health, resource usage and application errors are tracked continuously rather than discovered after the fact. Working with a specialist DevOps partner has been valuable because it gives the platform round-the-clock infrastructure expertise, while our team stays focused on the application, the data and the features our client needs next.
Data clean-up and log review as ongoing work
A platform with 40,000 vehicles, constant feed updates, enquiries and user activity generates enormous amounts of data and logs. Left unmanaged, that data slows queries down, inflates storage and makes it harder to spot real problems. Data clean-up and log review have therefore become ongoing, scheduled work rather than an occasional tidy-up, and part of that is planning how to archive data that is no longer needed day to day but is still important to keep, without disrupting the live platform.
The day the biggest feed failed
Vehicle stock reaches the platform through seven automated feeds that run multiple times a day. One of them comes from an industry-leading feed provider, and as more dealers joined that provider and more vehicles were added, the feed grew steadily larger. Every run meant processing a significant volume of data, several times a day, and eventually that load caught up with us: the feed failed.
The consequences were immediate and very visible. New stock was not loaded, vehicles that had already been sold were still on display for the public to enquire about, and dealers were fielding questions about cars they no longer had. On a lead-generation platform, our client's reputation was on the line, so we needed to act quickly.
We fixed the immediate problem and then went much further. We refactored key parts of the processing code to make it faster and far less demanding on the server. We added detailed logging of each run, so that we could measure data size and processing time and pinpoint exactly where the bottlenecks were. We started processing the feed in smaller chunks rather than in one heavy pass, and we added logic and checks to skip the parts of the feed that did not need to be processed on a given run. On top of that, every feed now has monitoring, reporting and failsafes: if a run fails, we are notified immediately and can intervene manually before the problem reaches users.
The result is a refined, highly streamlined processing system with data logging and reporting built in, and a level of reliability that is now close to flawless. That pattern of resolving the issue quickly and then engineering it out so it cannot happen again became one of the defining habits of this project.
Feature and complexity growth
Search: the feature we never stopped rebuilding
The clearest example of a year-one decision that had to be revisited is search. We launched with a basic but perfectly decent search that let users filter on the essentials. As the data grew and user expectations rose, that search had to evolve repeatedly. First we added more options for buyers to search with, such as colour, engine capacity, number of seats and whether a vehicle was on special.
The more interesting challenge was how to group and display vehicle model variants. A single model can have a long list of variants, and presenting every one of them for a user to choose from is a poor experience with far too many options. Grouping variants cleverly and logically made the underlying data cleaner and made searching much more intuitive for buyers. It is a good reminder that on a data-heavy platform, the quality of the user experience often depends as much on how the data is structured as on how the interface looks.
Multi-language support
Our client identified a significant gap in the market for an Afrikaans version of the platform. This was not a feature we bolted on quickly; it was a large, planned project in which we worked with a range of Afrikaans-speaking professionals and bodies to make sure the language and terminology were right. Adding a second language touches almost every part of a platform, from content and navigation to search, SEO and the structure of URLs, so treating it as a properly scoped project rather than a translation exercise was essential.
The Afrikaans version launched in mid-2025 and the results justified the investment: traffic increased by around 20%, with more leads for dealers and noticeably greater brand awareness.
Affiliates and integrations
Over time the client also introduced affiliates who market the sites, which changed the platform's risk profile in a specific way. When leads can originate from multiple partners, every lead has to be attributed to the correct source, because that attribution drives commercial relationships and payments. That required additional tracking throughout the enquiry journey, and because it was built properly and thoroughly tested from the outset, attribution has run without disputes or problems.
The most significant integration was with the industry-leading automotive data provider. It keeps the platform's makes, models and variants up to date, and it also supplies credit and fraud data on people making enquiries, which helps protect dealers from time-wasting or fraudulent leads. Alongside it, the platform now connects to finance calculators, newsletter subscriptions, YouTube and other services, each one another moving part that needs the same monitoring and failsafe thinking we applied to the vehicle feeds.
How the team grew with the platform
As the platform grew, so did the team behind it. We added developers on both the front end and the back end, as well as more QA capacity, but the role that grew the most was business analysis. On a platform of this complexity, the hardest part of any new feature is understanding exactly how it will interact with the data, the feeds, the integrations and the existing user journeys. Strong business analysts ensure that new ideas are properly understood and specified before a line of code is written, which is a large part of why the platform has been able to keep growing without becoming fragile.
What stands out most in hindsight is the pace. "The volume of features was remarkable," says Angelo, "as was the speed at which we needed to design, build and deploy them so that our client could stay nimble and competitive. It was fun, stressful and rewarding all at the same time."
Reporting and transparency: how visibility built trust
As the platform became more complex, the way we communicated with our client changed just as much as the technology did. What began as periodic project updates has become daily contact, with the client sharing feedback, new ideas and challenges, and our team responding with solutions that continue to grow the platform. That rhythm has turned the technology into a genuine commercial asset for the business rather than something that simply runs in the background.
A big part of that trust comes from transparency. Our client receives dashboards and daily summary emails that bring together the data on leads, enquiries and form submissions alongside the completion status of every feed. Instead of having to ask whether the overnight feeds ran or how many enquiries came through, they can see it for themselves at a glance, every morning. When something does need attention, they usually already know about it, and they know it is being handled.
Issues do still arise, as they do on any fast-moving, complex platform. What has made the client confident that everything is under control is how those issues are handled. We act quickly to resolve the immediate problem, and then we design and build a solution with failsafes that prevent the same issue from happening again. Over five years, that discipline has produced a far more rugged web application, and a client relationship built on evidence rather than reassurance.
Looking ahead: thinking big from day one
The platform is still growing. More integrations and features are on the way, and the next major step already on the radar is a mobile application version of the platform. That is exactly why we continue to plan big today, so that the foundation we have built can handle the next wave of traffic, data and transaction growth without needing to be re-engineered.
The biggest lesson this project has taught us, and one that now shapes how we architect every new platform from the very first day, is that you have to think big about scale, about marketing and about failsafes.
Scale in data. We ask what the data will look like in two, three and five years, how we will keep the platform fast as it grows, and how data that is no longer needed day to day but is still important will be archived without disruption.
Scale in features. We build on a solid framework that is designed to grow, because we expect a great deal of new functionality to be added over a platform's lifetime. Everything is structured according to best practice so that the business does not have to re-engineer the whole platform a few years down the line.
Scale in performance. We plan for increased traffic, load and transactions from the start. A useful question to ask of any architecture is whether it could cope with fifty times the traffic and a substantial increase in data and transactions, and if the answer is no, what would need to change.
Marketing, SEO and AI search. Growth on platforms like this one is driven by marketing, so the website and its data need to be structured to perform extremely well in search engines and AI-driven search. That means data that can be properly segmented, crawled and indexed, so that every vehicle, dealer and category has the best possible chance of being found.
Failsafes everywhere. With automated procedures and integrations flowing both into and out of the application, there are many moving parts that can fail. When they do, the platform must handle the problem gracefully, users must be treated in a friendly and helpful way, and the error must be actioned with preventative measures put in place so it does not recur.
Frequently asked questions
How do you know when a web application needs to scale?
The signs are usually gradual rather than dramatic. Intermittent errors, slower page loads and occasional failed requests are common early warnings, especially when server logs show the errors are resource related. The clearest indicator is when those technical problems rise in step with growth in traffic or engagement in your analytics. If marketing is working and the platform is struggling at the same time, it is time to plan the next stage of your infrastructure.
What is the biggest mistake companies make when a platform grows fast?
The most common mistake is building only for today. Platforms that are designed without considering how data, features and traffic will look in two to five years tend to need expensive re-engineering just as the business is gaining momentum. A close second is running automated feeds and integrations without monitoring and failsafes, so that failures are discovered by customers rather than by the team responsible for the platform.
Why separate the database from the web application server?
On a data-heavy platform, the application and the database compete for the same processing power and memory when they share a server. Separating them lets each be tuned and scaled independently, reduces the chance that heavy database work slows down the user experience, and makes the overall system more resilient as traffic and data volumes grow.
How does Redis caching improve web application performance?
Redis stores frequently requested data and query results in memory, so the application can return them almost instantly instead of asking the database to recalculate the same answers repeatedly. On platforms where many users request similar information, such as filter counts, search results and dealer pages, caching can dramatically improve speed; on the CHANGECARS platform it reduced average CPU load by at least 20 to 30%.
How do you prevent automated data feeds from silently failing?
Every feed should be monitored, with reporting that confirms whether each run succeeded and alerts that notify the team immediately if it did not. As feeds grow, logging data size and processing time for each run reveals bottlenecks early, and processing large feeds in smaller chunks while skipping data that has not changed keeps them fast and reliable. Daily summary reports and dashboards also give the business owner direct visibility of feed health.
How do you plan a platform architecture for future growth?
Start by planning for scale in data, features and performance, and by structuring the platform and its data for SEO and AI search from the outset. Choose a solid, well-structured framework that can absorb years of new functionality, ask whether the system could handle many times its current traffic, and build failsafes around every automated process and integration.
Is it worth adding a second language to a web platform?
It can be, when there is a genuine audience for it and the project is treated as more than translation. On the CHANGECARS platform, launching an Afrikaans version in mid-2025 increased traffic by around 20% and delivered more leads and greater brand awareness. The key is planning for the impact on content, search, SEO and URL structure, and involving native-speaking professionals to get the language right.
Is your platform ready for what comes next?
Whether your web application is already showing signs of strain, or you are planning a new platform and want to get the foundations right from the first day, our team has spent five years solving these exact challenges on a live, fast-growing platform, and two decades building custom software for businesses across South Africa, the UK and the US. Get in touch with Elemental to discuss your project, and let's talk about how to build something that keeps performing as your business grows.
