Every dealer group that reaches a certain size eventually asks the same question: do we keep buying software off the shelf, or do we build our own? The build vs buy automotive software decision usually surfaces after a string of frustrations - a DMS that will not give you the report you need, integrations that break, a pricing tool that disagrees with your gut, and vendors who move on their roadmap, not yours. At some point a board member or a sharp operations lead says the obvious thing out loud: we are big enough now, why don't we just build it ourselves?
It is a fair question, and it deserves a better answer than a reflex either way. Building gives you control and fit. Buying gives you speed and shared cost. Both have a failure mode that quietly drains margin for years. This article gives you a decision framework you can take into a real meeting - one that separates the parts of your stack worth building from the parts you should never touch, and that treats build and buy as a portfolio of choices rather than a single bet.
Reframe the question: it is a portfolio, not a coin flip
The mistake most groups make is treating build vs buy as a binary applied to the whole stack. It almost never is. A modern dealership runs on layers - a system of record, valuation and pricing, inventory and reconditioning workflow, CRM, lead routing, accounting, reporting. Some of those layers are commodities. Some are where you genuinely win. Treating them all the same is how you end up either building a payroll module you should have rented, or renting the one workflow that actually differentiates you.
A cleaner way to think about it is three buckets:
- Commodity - everyone needs it, no customer chooses you because of it, and the market has good options. Accounting, document storage, basic compliance. Buy.
- Differentiating - how you do this is genuinely better than the group down the road, and that edge shows up in margin or speed. Maybe it is your stocking logic, your reconditioning routing, your repricing cadence. Build or heavily customise.
- Core but shared - the spine everything plugs into, the system of record. You probably should not build this from scratch, but you must be able to read from and write to it freely.
Run every candidate through those three buckets before you cost anything. Most of the heat in build vs buy debates comes from arguing about the whole stack when the real answer is buy four of these and build one.
When building makes sense
Building is the right call far less often than ambitious teams assume, but when the conditions line up it is the only call. Building genuinely pays when all of the following hold.
You have a durable, specific edge
If your group has a way of pricing trade-ins or clearing aged stock that consistently beats the market, and that method is not available off the shelf, software is how you scale it across every site. That is a real reason to build. The test is whether the edge is yours and durable - not just a workflow a vendor has not got around to adding yet, which they will, and then your build is a liability.
You can fund the second decade, not just the first sprint
The seductive part of build is the demo. The expensive part is year three, when the original engineers have left, the framework is two major versions behind, and a regulation change means someone has to touch the pricing logic nobody fully remembers. If you cannot commit to staffing that indefinitely, you are not building software, you are renting technical debt from your future self.
The buy options genuinely do not fit
Sometimes the market really has not caught up - a cross-border data need, an unusual ownership structure, a workflow no vendor serves. If you have honestly evaluated the field and nothing fits, building is defensible. Be ruthless here, because not doing exactly what you want is true of every product and is not the same as being unable to do the job.
When buying wins
Buying is the right default for most of the stack, and the reasons are unglamorous but decisive. A vendor amortises the cost of building, maintaining, securing, and updating the software across hundreds of dealers. You will never match that on a single group's budget for a commodity capability. You get a tested product on day one instead of a roadmap. You get someone else carrying the on-call pager when a dependency has a security flaw in the middle of the night.
Buying also frees your scarce technical people for the differentiating work. The opportunity cost of build is the most underrated factor in the whole decision: every engineer maintaining a homegrown accounting integration is an engineer not building the stocking edge that actually moves your margin. For most groups, the smartest technical strategy is to buy aggressively on the commodity layer so you can afford to build narrowly where it counts. If you are still assembling your stack, the small dealership tech stack guide is a useful starting map of what to rent first.
The watch-out with buy is lock-in. A bought system that holds your data hostage in a proprietary format turns a reversible decision into a one-way door. That risk is manageable, but only if you make data ownership a contractual condition before you sign, not a renegotiation after.
The third option: extend a platform
The build vs buy framing hides a third path that often beats both: buy a platform and build on it. Instead of choosing between a rigid bought product and a from-scratch build, you take an API-first system that handles the heavy, shared infrastructure and you write your own logic on top of it. You buy the spine and the boring parts. You build the thin differentiating layer where your edge actually lives.
This is usually the best answer for a dealer group, because it gives you vendor leverage on maintenance and security while keeping the part that makes you money in your own hands. The viability of this path depends entirely on the platform's economics and openness - whether its data layer is genuinely open and extensible or just a walled garden with an API badge. The economics of an automotive data layer piece goes deeper on why that distinction decides whether extend is real or marketing. The related discipline of augmenting rather than replacing your existing systems is the same idea applied to rollout: add capability beside what works rather than ripping it out.
A decision framework you can use in the room
Here is the framework condensed into criteria you can score each candidate system against. Walk every layer of your stack through it.
| Criterion | Lean build | Lean buy | Lean extend a platform |
|---|---|---|---|
| Competitive impact | Core differentiator, durable edge | Commodity, no customer cares | Differentiator that sits on shared infrastructure |
| Market maturity | No product fits after honest review | Several good products exist | A solid platform exists with open APIs |
| Total cost over ten years | Funded indefinitely, eyes open | Lower via shared vendor cost | Mid: rent the spine, build the thin layer |
| Talent you can hire and keep | Yes, a standing team | Not needed | Small team for the extension layer |
| Speed needed | You can wait for build cycles | You need it working now | Fast on the platform, custom on top |
| Data ownership | You own it by definition | Only if contractually guaranteed | You own it if formats are open |
| Reversibility | Hard, you carry it all | Risk of lock-in | High if data is portable |
A practical sequence for the meeting: list each system, drop it into commodity, differentiating, or core, score it against the table, and only then talk money. Costing before classifying is how groups end up building the wrong things expensively. And whichever way each layer lands, treat your data as the asset and the software as the renter - a stance the single source of truth for vehicle data discussion sets out in full.
Where VehIQ fits
VehIQ is being built as the third option in this article made concrete: an API-first, AI-native infrastructure layer for European automotive that you extend rather than fight. It is designed to run alongside your existing systems first - augment, not replace - then expand across the value chain as trust builds, so you are never forced into a single all-or-nothing migration.
The parts VehIQ is designed to handle are the heavy, shared ones that rarely justify a from-scratch build: canonical European vehicle data with field-level lineage, valuations that show their sources and a confidence interval instead of one black-box number, and inventory intelligence such as days-to-sell and margin-at-risk. Crucially, it is built EU-sovereign and on open data formats the customer owns - which is the one condition that keeps your build vs buy decision reversible for years. VehIQ is pre-seed and still being built, so treat this as the design intent rather than a deployed track record; the point for your framework is that owning your data and extending a platform are not competing strategies, they are the same one.