Multi-Tenant Automotive SaaS: How One Stock Sourcing Platform Serves Many Dealerships
Building a software platform that serves a single customer well is a tractable engineering problem. Building one that serves thousands of customers simultaneously — each with different buying criteria, different market contexts, and different data — while keeping each customer's experience genuinely personalised and their data genuinely isolated, is a substantially harder one.
This article looks at the multi-tenancy challenge specifically in the context of automotive stock sourcing: why it matters, what the architectural decisions look like, and what it means in practice for the dealers who use the platform.
What multi-tenancy means in an automotive SaaS context
Multi-tenancy refers to a software architecture in which a single deployed instance of an application serves multiple distinct customers — called tenants — simultaneously. The infrastructure is shared; the data and experience are not.
For a stock sourcing platform serving multiple dealerships, this means one platform, one codebase, one set of servers — but each dealership sees only its own buying history, its own buying brief configuration, and recommendations derived from its own data. Dealer A cannot see Dealer B's purchase history, preferences, or shortlists, even though both are running on the same underlying system.
What makes multi-tenancy interesting in the automotive sourcing context is the tension between shared infrastructure and individualised intelligence. A platform that serves hundreds of dealers needs shared data pipelines for ingesting platform stock. But the intelligence applied to that stock — the ranking, the filtering, the personalisation — must be strictly per-tenant.
Why dealership data must stay isolated — and what breaks if it does not
Buying behaviour is commercially sensitive information. A dealer's purchasing history reveals their target stock profile, their pricing strategy, which platforms they prioritise, and what they consistently avoid. In aggregate, it is a detailed picture of their competitive positioning in the wholesale market.
If tenant isolation breaks down — if Dealer A's buying signals can influence Dealer B's recommendations — the platform becomes a mechanism for unintended intelligence sharing between competitors. Two dealers working the same regional market and using the same platform should not be able to infer anything about each other's strategy from the platform's behaviour.
Isolation must be enforced at the data layer, not just at the application layer. Row-level security in the database, scoped API access tokens, and careful audit of any aggregation that might inadvertently leak cross-tenant signals are all necessary.
Designing recommendation logic that is personalised per tenant
The core technical challenge of multi-tenant personalisation is the cold start problem combined with the small data problem. A large tenant with years of purchase history provides enough signal to train a genuinely individualised recommendation model. A small dealer who has been on the platform for three months and made 40 purchases does not.
The practical solution is a layered approach. At the base, a rules engine allows tenants to specify their buying criteria explicitly — grade requirements, fuel type preferences, model targets, spec minimums. This layer works from day one with zero purchase history.
As purchase data accumulates, a learned preference layer activates progressively. The system observes the delta between stated rules and actual buying behaviour — the places where a dealer consistently deviates from their explicit brief in a predictable direction — and adjusts recommendations accordingly.
Data architecture for multi-tenant automotive platforms
The data architecture of a multi-tenant sourcing platform has several distinct layers, each with different isolation requirements.
Stock data — the listings ingested from BCA, Manheim, Motorway, Carwow, and other platforms — is shared infrastructure. Every tenant benefits from the same ingestion pipeline. This data can be stored in shared tables because it contains no tenant-specific information.
Tenant configuration — buying rules, spec preferences, model targets, grade requirements — is fully tenant-scoped. This data is never shared and must be isolated at the row level with tenant identifier as a partition key.
Interaction data — shortlists, watchlist additions, purchases, passes — is the most sensitive category. Row-level security enforced at the database layer ensures that even application-layer bugs cannot expose this data across tenant boundaries.
Platform credentials — API keys and authentication tokens for each tenant's connected auction and listing accounts — require careful secrets management. These are stored encrypted, never logged, and accessible only by the ingestion processes that need them.
Scaling the ingestion layer across multiple auction and listing platforms
The ingestion layer is the part of a multi-tenant sourcing platform that most obviously benefits from the multi-tenant architecture. Instead of each dealer independently scraping and parsing BCA and Manheim stock, a shared ingestion pipeline does this once and makes the normalised result available to all tenants simultaneously.
The engineering challenge is normalisation. BCA and Manheim use different field names, different grading terminology, and different data models. Motorway and Carwow have different again. Building a normalisation layer that maps all of these onto a consistent internal schema is a significant but one-time investment that pays dividends across all tenants.
Once normalised, the stock data feeds into the per-tenant recommendation layer. The same underlying stock record might appear in the shortlist of 50 different tenants, ranked differently in each because each tenant's buying brief produces a different relevance score for it.
Onboarding new dealers — seeding recommendations before there is enough history
The first few weeks with a new dealer are the hardest for a recommendation system. There is no purchase history to learn from. The rules layer can be configured immediately based on a buying brief conversation, but the learned layer has nothing to work with.
The most effective bridge is portfolio upload — if a new tenant can provide a CSV of their recent purchases, the system can use this to bootstrap the learned preference layer before they have made a single purchase through the platform. Even 50 to 100 historical purchase records provide enough signal to meaningfully differentiate recommendations from pure rule-based output.
Guided configuration of the rules layer during onboarding also matters more than it might seem. A buying brief that is specific and accurate from day one produces much better initial recommendations than a generic one.
Reco Engine is built as a multi-tenant platform — each dealership gets their own buying logic, buying history, and recommendation model. Talk to us about onboarding your group on the founding members page.