How MOTO(acquire) Builds Dealer Software: At Dealerships, Not in an Office

• MOTO(acquire) builds its dealership software at dealerships, not only in an office.

• Software designed far from the store and handed to dealers to implement is, in the video's words, not a good way to build tech.

• Engineers who spend time in the store see the real workflow: who acts on a lead, how busy the service lane gets, and where handoffs break down.

• A fair question for any vendor is when the people who build the product were last inside a dealership.

• MOTO(acquire)'s acquisition tools, including MOTO(convert), MOTO(retain), MOTO(drive), and MOTO(social), are built to fit how a store already works.

Most dealers have lived this. A vendor demos a tool that looks great on a conference room screen, you sign, and then it lands in your store and nobody uses it. The desk ignores it, the service advisors work around it, and the used car manager goes back to the spreadsheet. That problem is the reason behind how MOTO(acquire) builds dealer software: the tools get built inside dealerships, not just in an office.

In this video, MOTO(acquire)'s head of engineering puts it plainly: "I don't sell cars, but I make car dealership software at dealerships, not in the office."

How MOTO(acquire) builds dealer software

The approach is simple. The people writing the code go to the stores where the software gets used. They watch how a trade appraisal actually moves, how the service drive actually runs, and where a lead gets dropped between departments.

That is different from the usual model. A lot of dealership software is designed somewhere far from the lot, then handed to your team with a training session and a login. As the video says, if vendors are "just building it in an office expecting you to implement it in your store, it doesn't sound like a good way to build tech."

The goal, in the video's own words: "we build software at dealerships that actually works."

Why does it matter where dealership software gets built?

Because a dealership is not an office. Your people are on the phone, on the lot, at the desk, and in the service lane, often all in the same hour. Software that assumes someone is sitting at a desk with time to click through screen after screen is going to lose to whatever is fastest.

When engineers spend time in the store, they see things that never show up in a requirements document:

• Which person actually acts on a trade-in lead, and how fast they need the information.

• What a service advisor can realistically do during a busy morning without slowing down the lane.

• Where handoffs between sales, service, and the used car department break down.

• Which data the team already trusts from the DMS, and which steps they skip.

Those details decide whether a tool gets used every day or becomes another login nobody remembers.

What engineers at a car dealer software company should be building

If you are evaluating vendors, this is a fair question to ask: when was the last time your engineers were in a dealership? Not the sales rep. The people who build the product.

Engineers at a dealer software company should be building around the store's real workflow. That means fewer steps for the person on the floor, information delivered to the person who can act on it, and integrations with the systems the store already runs on. MOTO(acquire) integrates with all major DMS platforms and many others, including Tekion, Dealertrack, CDK, Reynolds, and Auto/Mate. If a store uses a DMS we do not integrate with yet, we will build the integration.

Where this shows up in MOTO(acquire)'s tools

MOTO(acquire) builds software that helps dealerships acquire used vehicles, and each tool has to fit how a store already works:

• MOTO(convert): a website trade tool with instant valuations, firm offer requests, and monthly value tracking. It includes the free buying power tool.

• MOTO(retain): sends past sales and service customers their vehicle's value every month.

• MOTO(drive): service drive acquisition using DMS data and automated texts. It pushes VIN and miles to inventory tools, and the sales team is alerted when a customer is ready.

• MOTO(social): gives each person posting on social their own link, with leads attributed in the CRM.

MOTO(drive) is a good example of why store time matters. The service lane is busy, and advisors are not there to be buyers. MOTO(drive) stores consistently buy about 1% of their repair orders without dedicated service acquisition hires.

For more on how the team works, visit Inside MOTO(acquire). If you want to see what software built in dealerships looks like on your own website, book a demo and judge it against how your store actually runs.