What a car dealership mobile app actually has to track.
A car dealership mobile app is rarely one app. Walk a store on a Saturday and you will see four phones doing four jobs: a porter photographing a trade-in on the back lot, a salesperson logging a walk-in before the demo drive, an advisor writing up a repair order at the car, and a customer in the waiting area checking whether their approval went through. Each of those is a screen over one of three records the dealership already keeps. This page is about those records: the fields, the status rules, and the regulation that decides how the login has to work. Among the app examples on this site, it is the one where the primary key is a 17-character number.
The vendors that sell dealership software already cover a lot of this, and the page says what they cover. The interesting question is what a store does when its process does not match the vendor's screens, and what a car dealership app has to get right if the store decides to build its own.
See what the vehicle record needsThe short version
Three records, four phones.
Every car dealership app is a view over one of three records: the vehicle, keyed by its VIN and carrying a fixed status from in transit to delivered; the deal, a lead with a source, a vehicle of interest, a trade-in and a follow-up date; and the repair order, with the customer's concerns, the inspection results, the estimate lines and a timestamped approval. The phone it runs on decides which fields matter and who may see them: the lot, the showroom, the service drive or the customer's pocket. Get the records right first. The screens are the easy part.
Four apps, not one
Which car dealership app are you building?
The word dealership app hides four different products with four different users. They share a database. They should not share a login, a home screen or a status list.
| App | Who holds the phone | The record it edits | What it has to talk to |
|---|---|---|---|
| Lot and inventory app | Porters, photographers, the used car manager | The vehicle record: VIN, stock number, photos, lot location, status | The DMS inventory file, OEM allocation feeds, wherever listings are published |
| Showroom and lead app | Salespeople, the BDC, sales managers | The lead: source, vehicle of interest, trade-in, appointment, follow-up date | The CRM, the desking tool, the credit application in F&I |
| Service drive app | Advisors, technicians, the service manager | The repair order: concerns, inspection, estimate lines, approvals, status | The DMS service and parts modules, texting, OEM warranty systems |
| Customer-facing dealership app | Customers | Their vehicles, appointments, live repair status, approvals, saved cars | Service scheduling, repair order status, the inventory feed, push notifications |
The incumbents sell most of these screens already. CDK's service products, for example, put check-in on a tablet in the advisor's hands, run the multipoint inspection digitally and text customers videos to get repairs approved faster, all inside its Fixed Operations Suite. None of it carries a published price; every product page ends in a demo request or a contact form. That is the trade: a mature product on the vendor's status list, at a price you learn in a sales call.
The vehicle record
The vehicle record starts with the VIN.
Every vehicle on the lot has one identifier that never changes, never repeats and encodes more than most people realise. Under 49 CFR Part 565 a VIN is exactly 17 characters drawn from the digits and every letter except I, O and Q, and no two vehicles built under the federal safety standards within a 60-year window may share one. That makes it the primary key for the whole store: the lot app, the deal jacket, the repair order and the customer's glovebox all point at the same 17 characters.
What the 17 characters encode
Section 565.15 lays the VIN out in four parts, and a lot app should show them rather than treat the VIN as an opaque string:
- Positions 1 to 3 identify the manufacturer and the type of vehicle. A 9 in position 3 means the manufacturer is a low-volume one whose identifier continues in positions 12 to 14.
- Positions 4 to 8 describe the vehicle: make, line, series, body type, engine and restraint systems for a passenger car. For cars and light trucks, position 7 is always a letter.
- Position 9 is the check digit, a number or the letter X computed from the other 16 characters, there to catch transcription errors.
- Position 10 is the model year code, 11 is the plant, and 12 to 17 are the serial number, with the last five numeric for cars and light trucks.
Decode it, do not type it
Year, make, model, body class, engine and plant should never be typed by a porter. NHTSA's vPIC vehicle API decodes a VIN into those fields as key-value pairs, is free, asks for no API key, and accepts partial VINs with an asterisk for the characters you do not have. NHTSA does run automated rate control on it, so the right pattern for a lot app is to decode once when the car is received, store the result on the vehicle record, and never make a screen wait on a live decode.
Before the decode comes the check. A mistyped VIN is the most expensive typo on the lot: it puts the wrong car in the DMS, on the history report and on the buyer's paperwork. The check digit catches most single-character mistakes before any of that happens, and the rule for computing it is public.
Try it
Does this VIN pass its check digit?
Type or paste a VIN. The checker applies the three rules a lot app should apply before it saves anything: the length, the character set, and the position 9 check digit from 49 CFR 565.15.
- Exactly 17 characters49 CFR 565.13(b)
- Letters and digits only, never I, O or Q49 CFR 565.13(g)
- Position 9 matches the computed check digitNeeds all 17 characters first
What the structure says
Enter a VIN to see its manufacturer identifier, model year, plant code and serial pulled out of the 17 characters.
Beyond the decode
The fields the VIN does not carry
The decode gives you what the factory knew. The lot app has to capture what happened since, and most of it has a date and a name attached:
- Stock number, separate from the VIN, because the DMS and the lot both key on it
- Odometer at every touch: intake, trade-in appraisal, repair order in, delivery
- Exterior and interior color, and the options the VIN decode does not carry
- How and when the car was acquired: trade, auction, OEM allocation, dealer swap
- Cost, asking price and a history of every price change with who changed it
- Photos and a walkaround video, each with the date it was taken
- Lot location and key tag number, because finding the car is half the job
- Title status and, on trades, the payoff and who it is owed to
- Reconditioning notes and the history report pulled at intake
- The warranty terms that go on the window, as-is or dealer warranty
- Status from a fixed list, with a timestamp and a name on every change
- Days in stock, counted from the received date, not from the front line date
Status, not free text
Lot status: a fixed list, not a text box.
Ask three people at a store what "in stock" means and you will get three answers: on the ground, on the website, or ready to sell. A lot app settles the argument with a short list of states, rules about which moves are allowed, and a name and a timestamp on every change. This is one workable list; yours may add a state for OEM certification or a loaner fleet.
| Status | What it means | What moves it forward |
|---|---|---|
| In transit | Allocated or bought, not on the ground yet. | Received when the VIN is scanned at the gate. |
| Received | On the lot, not for sale. Days in stock start counting here. | In recon once the intake inspection is written up. |
| In recon | Reconditioning under way, in your shop or at a vendor. | Front line when the work is signed off and the photos are taken. |
| Front line | Priced, photographed, listed, keys where they should be. | Sold pending the moment a deal is written on it. |
| Sold pending | Contract in hand, deal not yet funded or delivered. | Delivered on delivery, or back to Front line if the deal unwinds. |
| Delivered | Gone, paperwork complete. Locked. | Nothing. This is an end state. |
| Wholesale | Sent to auction or another dealer instead of being retailed. Locked. | Nothing. This is the other end state. |
The names matter less than two rules. A car cannot skip from Received to Sold pending without passing through recon and the front line, because that is how unphotographed, unpriced cars end up on a contract. And days in stock start at Received, not at Front line, because the two weeks a car sat behind the body shop are the two weeks the used car manager most needs to see.
The deal record
Leads and the showroom: the deal record.
The sales floor runs on a record that starts as a lead and ends as a delivered car, and every CRM in the industry models it. What changes from store to store is which fields are required, and when.
Source
Walk-in, phone, internet lead, referral, service drive. It is the only way to know what the advertising bought.
Contact and consent
Name, phone, email, and whether the customer agreed to be texted, with the date they agreed.
Vehicle of interest
By stock number or VIN, not free text, so the lead follows the car if it is sold to someone else.
Trade-in
Its VIN, odometer, condition photos, the appraisal amount and who appraised it. Decode the VIN here too.
Salesperson and manager
Who owns the lead and who approved the numbers. Both change hands; the record has to show when.
Appointment and follow-up due
A date and time for the next contact, not a note that says soon. Overdue follow-ups are the manager's morning list.
Status
New, contacted, appointment set, shown, written up, sold, delivered, lost. Lost needs a reason from a short list.
The showroom log rule
No demo drive before the visit is logged. Managers fight over this field more than any other, and the only fix that holds is making the log faster than skipping it: a name, a phone number and a stock number. Three fields, ten seconds, at the car.
That capture-at-the-door problem is not unique to car lots. A listing agent solves the same one with an open house app: get the name before the tour, or the visit never becomes a lead. The dealership version has one extra field that pays for the whole app, the trade-in. Its VIN goes through the same check and decode as the inventory, its photos land in the appraisal queue, and the appraisal amount is recorded with the name of whoever set it.
The repair order
The service drive: the repair order.
Service is where a dealership app touches the most customers most often, and where the record already has a name and a number: the repair order. On a phone or tablet it needs:
- Repair order number, VIN and odometer in
- The customer's concerns in the customer's words, not the advisor's translation
- Advisor, technician and the promised time
- Multipoint inspection with green, yellow or red per item and a photo on anything not green
- Estimate lines with parts, labor and the price the customer was shown
- Approval with who gave it, when and how: in person, by text or in the app
- Status from a fixed list, timestamped, visible to the customer
One status list, shared with the customer
Waiting for approval is the state that costs money, because the car sits on a lift while someone plays phone tag. It is also the state a customer-facing app exists to shorten: the yellow and red items, with a price each and a photo, and a tap that writes a timestamped approval onto the repair order. CDK's service lane products attack the same state with texted videos of the repair.
The record underneath is the same one an independent shop keeps. The auto repair shop app page walks through the write-up and approval flow in detail, and everything there applies to a dealership service drive with one addition: the warranty claim, which needs the VIN, the mileage and the failed part recorded exactly as the OEM wants them.
The customer's phone
The customer-facing car dealership app: what earns the install.
A customer installs a single dealership's app for one reason: it does something the website and a text thread cannot. Six screens qualify, and every one of them is a view over a record the internal apps already keep.
My vehicles
Every car the customer has bought or serviced here, by VIN, with the service history and the next service due.
Book service
Pick the car, pick the concern, pick a slot. If the app cannot see the real schedule, this screen is a contact form.
Live repair status
The repair order status list above, in plain words, with the inspection photos attached.
Approve or decline
Yellow and red items with a price each, and a tap that writes a timestamped approval onto the repair order.
Saved cars
Inventory the customer is watching, with a notification when the price changes or the car sells.
Trade-in offer
VIN, odometer and six photos from the customer's driveway, landing in the same appraisal queue the lot uses.
Notice what is missing: a coupon wall, a news feed, a rewards balance. Those can come later, once the app has a reason to be opened. The screen that earns the install is live repair status with approvals, and it is only as good as the repair order behind it, which is why the customer app is the last of the four to build, not the first.
Customer information
Customer information and the Safeguards Rule.
A dealership that arranges financing or leases vehicles holds credit applications, and that puts it under the FTC's Safeguards Rule, 16 CFR Part 314. The rule's own list of example financial institutions includes an automobile dealership that leases vehicles for longer than 90 days. Its definition of customer information is any record containing nonpublic personal information about a customer, in any form, which describes the lead record and the deal jacket exactly. Five of its requirements land directly on how a dealership app is built:
Multi-factor authentication for any individual accessing any information system
A password alone does not qualify. A second factor, a device or a biometric, does.
Encryption of customer information in transit over external networks and at rest
The credit application on a salesperson's phone and the database behind it, both encrypted.
Access limited to the customer information each user needs for their duties
Roles. A porter sees vehicles, not deals. A customer sees only their own record.
Secure development practices for in-house developed applications
Written explicitly for the case where you build your own. The rule expects it.
Monitoring and logging of authorized users' activity
Who opened which record, when. The same audit trail the lot status already needs.
Section 314.6 excuses stores holding information on fewer than 5,000 consumers from some elements, the written risk assessment, penetration testing, the incident response plan and the annual report to the board among them. It does not excuse them from the five above. The rule also requires an unauthorized acquisition of unencrypted information on 500 or more consumers to be reported to the FTC within 30 days of discovery, which is one more argument for encrypting the record in the first place.
This is where the login stops being a design choice. Every person who opens the app gets a second factor, a role that limits them to the records their job needs, and a log entry. Customers authenticate too, and see only their own vehicles and repair orders. How that gets wired, the sign-in flow, the second factor, the roles table, is covered in the guide to adding user login, and it is worth reading before the first screen is described.
Picking an approach
Off the shelf, white label, or your own?
None of the records above needs exotic software. What decides the approach is how closely your fields, statuses and roles match the ones a vendor has already decided on.
| Approach | Fits your process | Talks to your DMS | Who maintains it | Cost model |
|---|---|---|---|---|
| DMS or CRM vendor's own mobile app | Their screens and their status list | Yes | The vendor | Quote and contract |
| White-label customer app | A template with your logo | Depends on the integration | The vendor | Quote |
| Spreadsheet plus a group chat | Anything, until it drifts | No | You, by hand | Free tools, your time |
| Custom-built dealership app | Your fields, your statuses, your roles | If you wire it: file export, API or manual | You | A flat subscription |
What it costs
What does a car dealership mobile app cost?
Mostly, a number you learn on a call. CDK publishes no prices on its product pages, DealerSocket's site does the same, and both route you to a demo. A store that builds its own pays a flat subscription instead: on Newly it is $25 a month, there is no free plan, and publishing on iOS also needs your own Apple Developer Program membership. The cost that matters more than either is the week someone spends writing the fields and statuses down before anything is built, because that week is what a vendor contract never gives you back.
When to build your own
Building a car dealership app around your own process.
The honest reason a store builds its own app is not price, it is fit. A used car operation with its own recon stages, a group that appraises trades centrally, a service drive that promises a status text at every state change: each has a record that no vendor's schema quite holds, and the choice is to bend the process or bend the software. That gap is what Newly is for. Describe the record you actually keep, the fields, the status list, who may change what, and it builds a real native app around your process. On iOS the finished app goes through App Store Connect from your own Apple Developer account, and the current version produces no Android release builds, so plan for iPhones on the lot for now.
The order matters. The common failure is to start with the customer screen and work backwards into records that do not exist yet.
- 1
Pick the phone
Lot, showroom, service drive or customer. One record per app to start. The customer app comes last because it depends on the other three being right.
- 2
Write the record down
The fields above, on paper, with a mark against the ones that are required before a status can change. This is the cheapest hour in the whole project.
- 3
Fix the status list
The names, the legal transitions, and who may make each one. A porter can move a car to Received; only a manager can move it to Wholesale.
- 4
Decide the VIN flow
Scan, validate the check digit, decode once with vPIC, store the decode. Never let a screen depend on a live decode.
- 5
Name the source of truth
The DMS owns the deal and the accounting. Your app owns the photos, the lot location and the inspection. Write down which fields flow which way, and how: export, API or a person.
- 6
Design the login for the Safeguards Rule
Multi-factor authentication, roles that limit what each person sees, and a log of who opened what.
- 7
Ship to the people who touch cars first
Porters and advisors will tell you within a week which fields are wrong. Customers will just delete the app.
Sources
Where the specifics came from.
Four things on this page come from a primary source rather than from how stores tend to work:
FAQ
Car dealership apps, answered.
A car dealership mobile app is a phone or tablet app that puts one of the dealership's core records in someone's hand: the vehicle record for the lot team, the lead record for the sales floor, the repair order for the service drive, or a customer's own vehicles, appointments and approvals in a customer-facing app. Most stores end up needing more than one of these, and the common mistake is treating them as a single app with a single login.
Start with the VIN, not the home screen.
A dealership app lives or dies on three records that already exist: the car, the deal and the repair order. Write them down, fix the status lists, then build the app around them in Newly.