Automotive Software Development Cost: Six Modules, and the One That Is Already Written

11 min read
01 Nov 2026
Automotive Software Development Cost: Six Modules, and the One That Is Already Written

An automotive dealer platform costs $30,000 to $75,000 for phase one. That is 750 hours at a $40 to $100 rate band, or about $48,750 at a $65 blend. The honest span across the six modules is 510 hours at every minimum to 980 at every maximum.

The six: the dealer and inventory model at 100 hours, service scheduling and workshop at 160, parts catalogue and supersession at 130, telematics ingest at 170, warranty and claims at 100, and fiscal and compliance output at 90. Each sits inside a published range, so move any line and watch the total.

This is cheaper than most verticals we price, and the reason is instructive. A dealer group already owns a DMS. You are not replacing the system of record; you are building the layer it cannot express. That is why the number starts at 750 rather than the 1,300 to 1,500 a from-scratch platform costs in healthcare or property.

Here is the ordinary failure that explains what you are buying. A customer books a 08:00 service online. The booking lands in your scheduler. The job needs a diagnostic technician and a ramp, and the ramp is free but the only diagnostic technician is on another job until 10:30. The customer arrives, waits two hours, and leaves a review. Nothing was broken. The scheduler simply did not know that a booking is a claim on two resources, not one.

A dealer group is six systems pretending to be one

Most dealer groups run a DMS, a CRM, a parts catalogue, a workshop diary, a warranty portal and a spreadsheet. The spreadsheet is load-bearing. It usually holds whatever the DMS could not: courtesy car allocation, technician skills, the discount matrix a particular manufacturer insists on.

What a build is actually for is giving those six one shared vocabulary. A vehicle has to mean the same thing in the service diary and the parts catalogue. A customer has to be one record even though the DMS keyed them on account number and the CRM on email.

The dealer and inventory model is 80 to 160 hours and it is the cheapest module to get right and the most expensive to get wrong. Every later module reads it. If you model a vehicle as a stock item, you cannot represent a customer's own car arriving for service. If you model it as a customer asset, you cannot represent the nine identical units on the forecourt.

The answer most groups land on is two entities with one identity: a vehicle, which has a VIN and a history, and a stock unit, which is a vehicle you currently own with a price and an age. A trade-in moves between them, which is exactly the event that breaks single-entity models.

Stock age is the other thing the model has to carry, because it is how the business is run. A unit at 120 days is a different commercial object from the same unit at 20 days, and the people who need that number — the sales manager, the group accountant, the manufacturer running a stocking programme — all want it computed from the same date. Groups that let each report derive its own ageing end up with three answers and an argument every Monday.

The service bay is the business, and the schedule is the constraint

New car margin is thin and everybody knows it. Service and parts carry the group. That makes the workshop module — 100 to 190 hours — the one with the clearest return.

A workshop booking is a claim on three things at once: a bay, a technician with the right qualification, and the parts. Book against only the bay and you produce the two-hour wait above. Book against all three and you have built a small constraint solver, which is why the range tops out at 190.

The qualification part is where most generic scheduling software gives up. A hybrid or EV high-voltage job needs a certified technician, and that certification expires. An MOT or state inspection needs a tester. Your scheduler needs to know who holds what and when it lapses, which means the technician record carries qualifications with expiry dates and the booking engine refuses a job it cannot staff.

Parts availability is the third leg and it is the one that turns a well-run diary into a bad day. A booking that needs a part you do not hold should either order it or refuse the slot. Workshops that skip this run at a high rate of jobs that start and stop.

Courtesy cars are the part that looks like an afterthought and behaves like a second inventory. A courtesy vehicle has its own availability, its own insurance constraints about who may drive it, and its own cleaning and refuelling turnaround between customers. Book one without modelling the turnaround and you promise a car that is sitting dirty on the forecourt. Most groups run this in the spreadsheet precisely because the DMS will not hold it, which makes it one of the clearest candidates for the build.

No-shows are a capacity problem disguised as a customer problem. A missed 08:00 appointment is a bay and a technician paid for and unused, and the recovery is a standby list rather than an angry phone call. That means the scheduler needs to know which jobs could be pulled forward and whether their parts are on the shelf, which is the same question the booking engine already answers. Built once, used twice.

Parts supersession is the problem nobody scopes

Ask for a parts catalogue and you will be quoted a product table. That is not what a parts catalogue is.

A manufacturer replaces part A with part B, then replaces B with C. Sometimes C fits everything A fitted. Sometimes it fits only vehicles after a certain build date. Sometimes two old parts supersede into one new one, and occasionally the chain runs backwards because a supersession was withdrawn.

So the catalogue is a graph with validity rules, and the question a counter clerk actually asks is not "what is part A" but "what do I sell this customer, for this VIN, today". That query has to walk the chain and apply fitment.

A workshop booking as a claim on three resources at once: a bay, a technician with current certification, and the parts on the shelf under either number.

This is the 90-to-170-hour module, and the hours are almost entirely in that query and the data it needs. Groups that treat it as a lookup table discover the problem when a technician fits a superseded part that does not fit, and the labour to remove it is not recoverable from anyone.

Stock on hand has the same shape. A part you hold under its old number is still sellable under the new one, and if your stock view does not know that, you will order a part you already have on a shelf.

There is a pricing consequence too. The superseded part and its replacement frequently carry different prices, and the manufacturer's warranty reimbursement is calculated against one of them rather than whichever you happened to hold. A catalogue that cannot say which number was fitted and which was billed will produce warranty claims that look wrong to the manufacturer and right to you.

Warranty claims fail on evidence, not entitlement

Warranty is 70 to 140 hours and the reason it is not cheaper is that a claim is a document package, not a form.

The manufacturer is not asking whether the repair was covered. It is asking you to prove it. That means the claim carries the VIN, the mileage at the time, the fault code read from the vehicle, the labour operation code and its allowed time, the parts fitted with their numbers, and often photographs of the failed component before it was replaced.

Miss one and the claim is rejected, and rejections arrive weeks later when the technician who did the job has forgotten it. The groups that recover warranty revenue reliably are the ones that capture the evidence at the moment of the repair rather than reconstructing it at claim time.

That is a design decision with a cost. It means the job card has mandatory fields that depend on whether the work is warranty or retail, and it means photo capture in the workshop on a device a technician will actually carry.

The economics justify it on their own. Warranty work is a material share of workshop revenue for a franchised group, and a claim rejected for missing evidence is not merely delayed — the labour and the part have already been spent. A group that moves its rejection rate down by a few points recovers more in a quarter than the module cost to build, which is the rare case where a software line item pays back inside the first year without any growth assumption.

Resubmission is the other half. Rejections arrive in batches with manufacturer-specific reason codes, and someone has to work them. If your system cannot show a rejected claim next to the original job card and the evidence captured at the time, that work happens in email and most of it does not happen at all.

Fiscal output is where a build meets the tax authority

Sixty to 120 hours, and the range is entirely about which markets you operate in.

An invoice from a dealer group is a regulated document in more places every year. India requires e-invoicing through the Invoice Registration Portal above a turnover threshold, which means an IRN and a QR code on the document before it is valid. Gulf markets have their own e-invoicing regimes with their own clearance models. European markets are moving the same way.

Treat this as a reporting feature and you will rebuild it. It belongs at the point the invoice is created, because a document that has to be cleared by an authority before issue cannot be produced by a nightly batch.

Telematics is a module here and a post of its own

The sixth module, telematics ingest and join, is 110 to 200 hours and it is in the 750. We have written about it at length elsewhere, because the questions it raises — retention, resolution, the VIN join, and what the rules now require of the data path — do not fit in a section.

The short version for scoping purposes: ingest itself is roughly a fortnight, and the cost sits in how long you keep the data and at what resolution. If telematics is the reason you are building, read the telematics platform costing and treat this post as the dealer-side scope around it.

Phase one, module by module

Every competitor publishes a total with no hours behind it. Here are the hours.

Module

Hours

Dealer and inventory model

80 to 160

Service scheduling and workshop

100 to 190

Parts catalogue and supersession

90 to 170

Telematics ingest and join

110 to 200

Warranty and claims

70 to 140

Fiscal and compliance output

60 to 120

The worked example takes a mid-point from each: 100 plus 160 plus 130 plus 170 plus 100 plus 90, which is 750 hours. At $40 per hour that is $30,000. At $100 it is $75,000. At a $65 blend, about $48,750.

Deliberately outside that number: the DMS licence, telematics hardware, and any type approval or PCI assessment fee. The first two are yours to buy and the third belongs to an accredited body rather than to us.

Invitation to scope a dealer platform against an existing DMS with Zyneto's team

What moves the number most

Sites and manufacturers, in that order. One workshop is a different system from six, but six workshops under one franchise agreement are closer to one than they look. Six sites across three manufacturers is the expensive shape, because each manufacturer brings its own warranty portal, its own labour operation codes and its own parts catalogue format.

Second is the DMS you already run. A modern one with a documented API is a fortnight of integration. An older one where the supported integration path is a nightly file export changes the architecture of everything downstream, because now your platform is reconciling rather than reading.

Third is markets, through the fiscal module and nothing else. One market is at the bottom of the 60-to-120 range. Three markets with different clearance models is at the top of it, and the work is in the document rather than the arithmetic.

Data migration deserves its own line and rarely gets one. Bringing across open workshop jobs, parts stock under current and superseded numbers, and warranty claims still in flight is a different exercise from exporting a customer list. The parts stock in particular has to arrive already reconciled to the supersession chain, or the first stock count after go-live will not balance and nobody will know whether the system or the shelf is wrong.

What barely moves it: the number of screens, whether the customer-facing booking is a web app or native, and the visual design. Those are the first three questions we are usually asked and they sit inside normal variance.

Build, buy, or build around the DMS

For almost every group the answer is build around.

Buy, if your group is single-site and single-franchise. The DMS vendors' own modules will fit you, and nothing in this post is worth the money at that scale.

Build around the DMS, which is where nearly all of our automotive work sits. Keep the DMS as the system of record for vehicles, customers and invoices. Build the layer it cannot express: the booking engine that understands technician qualification, the supersession query, the warranty evidence capture. That is the 750 hours above.

Build fully, when the DMS is the constraint on the group's growth. This is rare and it is usually a group that has outgrown a regional DMS and cannot get an API out of it at all.

The middle path has a sequencing advantage worth naming. Building around the DMS means you can ship the workshop scheduler on its own, prove it in one site, and add parts and warranty afterwards, because each reads the system of record rather than replacing it. A full replacement has no such slice: the first thing you can usefully turn on is everything.

Three scoping questions covering manufacturers, DMS integration and invoicing markets

Where dealer builds actually fail

Three failures, none of them technical.

The first is discovering the DMS integration path in month two. The whole architecture depends on whether you can read the system of record live or have to reconcile a nightly file, and that question is answerable in week one with a phone call to the vendor.

The second is scoping the parts catalogue as a table. Supersession is the module that silently doubles, and it doubles after the data arrives, which is usually late.

The third is warranty built as a form. A claim that is assembled at claim time instead of captured at repair time will be rejected at a rate nobody forecast, and the revenue it loses is larger than the module cost.

The cost question has a short answer and it is the arithmetic above. The longer answer is that a dealer platform is cheap because the DMS already did the expensive part, and the moment you forget that is the moment the estimate stops being 750 hours.

FAQs

A dealer platform phase one costs $30,000 to $75,000, which is 750 hours at a $40 to $100 hourly band, or about $48,750 at a $65 blended rate. The span across the six modules runs 510 hours at every minimum to 980 at every maximum. It is cheaper than most verticals because a dealer group already owns a DMS, so the build is the layer around a system of record rather than a replacement for it.

Six. The dealer and inventory model at 80 to 160 hours. Service scheduling and workshop at 100 to 190. Parts catalogue and supersession at 90 to 170. Telematics ingest and join at 110 to 200. Warranty and claims at 70 to 140. Fiscal and compliance output at 60 to 120. The worked example takes a mid-point from each and totals 750 hours.

Because a parts catalogue is a graph, not a table. A manufacturer replaces part A with B and then B with C, and the replacements carry fitment rules that depend on the vehicle's build date. Occasionally two parts supersede into one, and occasionally a supersession is withdrawn. The query a counter clerk needs is "what do I sell for this VIN today", which has to walk the whole chain and apply fitment, and your stock view has to know that a part held under an old number is sellable under the new one.

Three things sit outside the build number. The DMS licence, which you buy from your dealer management vendor. Telematics hardware, if you are fitting devices to vehicles. And any type approval or PCI assessment fee, which is paid to an accredited body rather than to a development team. Hosting and ongoing manufacturer portal fees are operating costs rather than build costs.

Build around it, unless you cannot get data out of it. The DMS is the system of record for vehicles, customers and invoices, and replacing it is a far larger project than the one priced here. The build that pays is the layer the DMS cannot express: a booking engine that understands technician qualification and parts availability, the supersession query, and warranty evidence captured at the repair. Replacing the DMS entirely makes sense mainly for groups that have outgrown a regional system with no usable API.

A 750-hour phase one runs about 3 to 4 months with a team of 4 to 5 people delivering 600 to 700 useful hours a month. The limiting factor is usually not engineering. It is getting a documented integration path out of the DMS vendor and getting the parts data in a usable shape, both of which should start in week one.

Telematics ingest and join is one of the six modules at 110 to 200 hours and it is inside the 750. The depth sits in a separate post, because retention period, data resolution, the VIN join and the rules governing the data path are each decisions with their own cost. If connected-vehicle data is the reason you are building rather than a feature of a dealer platform, start there.

Vikas Choudhary

Vikas Choudhary

Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.

Let's make the next big thing together!

Share your details and we will talk soon.

Phone

We respond to all inquiries within 1 hour.

WhatsApp
Email
Book a Meeting