Why we built RooftopOS (and what every dealer-tech vendor got wrong)

Twenty-five years on the desk, and a stack nobody could count

I've run F&I desks in Connecticut for 25 years, and I still run one today — inside the store that is RooftopOS's founding design partner. The customers page names it and sets out that relationship in full. Everything below is written from that seat.

The day I sat down to list the dealer-tech vendors a store this size pays for every month, the list ran longer than anyone expected, and I still wasn't sure I had all of them. Every one had its own login, its own renewal cycle, and its own "AI feature" that 2024 added to a slide deck. None of them talked to each other, and none talked to our DMS without a paid integration on both ends.

This post is about why none of it was good enough, and why we ended up building our own operating system instead of buying one more thing to log into.

What every dealer-tech vendor got wrong

There are four mistakes I see consistently across the vendors I've used, demoed, and walked out of QSP rooms with. They're not character flaws — most of these companies are run by smart people doing their best inside a structure that pushed them in a particular direction. But they're real, and they compound.

Mistake 1 — Vendor sprawl as a feature, not a bug

Almost every dealer-tech company is built to be a point solution. A widget for trade-in. A widget for window stickers. A widget for service-drive video. A widget for digital retailing.

Every widget needs its own login, its own contract, its own training, its own integration with the DMS. Every widget owns a slice of the customer record and gets defensive about sharing it. The "integration" between two widgets is usually a CSV export and a manual upload, or a paid Zapier-equivalent middleware.

This isn't a bug from the vendor's perspective. The narrower the surface area, the easier it is to charge separately. The more separate things you charge for, the bigger your TAM looks on the next pitch deck. Vendor sprawl is a feature for them. It's a tax on us.

Mistake 2 — Compliance as paperwork

The FTC's CARS Rule was struck down before it took effect. What did not change is Section 5 of the FTC Act, which prohibits unfair or deceptive acts or practices, or the state UDAP and add-on disclosure statutes a pricing dispute actually gets argued under. Those were never dependent on the CARS Rule, and they are what a store answers to.

What did our existing vendors do? Sent us a one-page PDF with suggested disclosure language. Maybe a checkbox somewhere in their admin panel.

That's not compliance. Compliance is a per-VIN audit trail that ties the version of the disclosure the customer saw to the timestamp they signed at to the IP address they signed from. Compliance is being able to answer the question "what exactly did this customer agree to on this exact date" three years later, without rooting through email screenshots.

We needed software where compliance was enforced at the database level, not bolted on with a checkbox.

Mistake 3 — AI bolted on as theater

In 2024, every vendor I worked with shipped an "AI feature." Most of the time, it was a pattern matcher running on top of an existing rule engine — the same business logic they had in 2019, with a chat box on top, marketed as "agentic."

Real AI in a dealership looks like this: photos drive condition scoring that meaningfully changes the appraisal. Voice agents handle inbound and outbound calls and write back to the same pipeline your team is working. The AI doesn't replace your appraiser, your BDC, or your GM — it gives them better defaults so they spend their time on the deals where human judgment actually matters.

That requires building AI into the spine of the product. Not the surface.

Mistake 4 — The per-VIN tax

Almost every successful month makes you poorer with most dealer-tech vendors. You buy more cars, you trigger more "events," you pay more in per-VIN or per-message fees.

This is structurally insane. Pricing should attach to the rooftop, not to the VIN. We pay for the capacity, not for the throughput, because the capacity is what costs the vendor money to deliver. If you're growing, you're already paying more in cost-of-goods. The tooling shouldn't tax growth.

What an operator-built OS looks like

We sat down and wrote out the principles we wanted for whatever we built next. They came out short:

• One platform, one login, one customer record. Applications ship inside the same product, sharing the same database, the same record of what happened, the same customer profile. No CSV exports between applications.
• Per-rooftop pricing. Subscriptions quoted per rooftop, with any usage or service limits written into the order form — not billed per vehicle and not billed per event.
• Compliance enforced at the database, not at the form. Versioned consent, and a tamper-evident per-VIN file for any disclosure or signature collected. Read that precisely: it is a record the applications write, not a self-service export control. There is no audit log a store can query or export for itself today, and the Trust Center publishes the state of that control rather than letting this paragraph imply one.
• Dealer-owned data. Records are exportable on request, and RooftopOS carries the request out. The dealer's customer list is the dealer's. We don't resell it, we don't enrich it for someone else's marketing, we don't lock you in by hoarding the data.
• AI in the spine, not the surface. Re-appraisal, voice, lead routing and pricing decisioning belong in the pipeline the rest of the product already runs on, rather than chat-boxed onto the side of it. That is the architecture we're building toward, not a description of what has shipped: the AI acquisition agent is In Development today, and every application on this site carries its real status.
• Built by operators. Every feature has to survive a desk-up review with the people who would have to run it on a Saturday.

What we're shipping

The first application is AutoCurb — direct-from-consumer acquisition. Three channels (off-street, service drive, in-store trade), one pipeline, and a full audit trail. What a direct unit is worth against the auction is arithmetic a store should run on its own numbers, and the model does exactly that. AutoCurb is Live at the founding design partner.

Two more applications run on the same platform:

• AutoLabels — Live. Window stickers and addenda built for FTC Act Section 5 and state disclosure law, with versioned disclosures pinned to the deal.
• AutoFilm — Pilot, under a limited early-access agreement and not generally available. Walk-around and inspection video for the service drive and online retailing, captured against the VIN.

All three ride the same pipeline. All three write to the same vehicle record. The dealer logs in once.

Where you can pilot

If you run a one-to-ten-rooftop group, you're who we built this for. The evaluation runs sixty days on one rooftop, on your domain and your branding. We establish a baseline before go-live, agree the success metrics in writing, come in with a runbook, and live in the dashboard with you while you run it. The commercial terms are settled in the scoping conversation and written down before anything starts.

If that sounds like the right kind of headache to take on, apply for a 60-Day Proof of Value. If you want a 20-minute version of this post on a Zoom call, request a platform demo.

We're not trying to sell you one more thing to log into. We're trying to replace the stack you already have.