A representative build: a seven-rooftop acquisition platform running its stores, its capital, and its deal pipeline out of one authenticated web application, where the dashboard, the written plan, the lender deck, and the Excel forecast are all generated from the same model.
Consolidated on one chart of accounts across four brands
Owner and stakeholder, with the navigation itself as the access policy
Screen, plan, deck, and spreadsheet all downstream of the same calculation
Assessment to full deployment, with a usable release in week eight
A group assembling a multi-store platform was running the entire venture out of a spreadsheet workbook and a slide deck. Both were maintained by hand, and they had stopped agreeing with each other somewhere around the third revision.
The practical consequences were the ones every group of this kind eventually hits. A question from a capital partner took two days to answer because the answer meant rebuilding a tab. A change to one acquisition assumption meant touching the model, the narrative, and the deck separately, and remembering all three. Nobody could say with confidence which version of the seven-store forecast was current. And there was no way to give an outside partner a look at the numbers without either sending a file that would be stale in a week or granting access to everything, including live broker packages under NDA.
A private web application with a computational model underneath it, replacing the workbook rather than presenting it. The core decision was that every artifact — the dashboard, the written plan, the pitch deck, and the Excel forecast — is generated from one set of assumption files, so there is no second place where a number can be wrong.
Consolidated P&L with each rooftop underneath it, and departmental detail for new, used, F&I, fixed operations, parts, and marketing. Every line carries a written definition and the benchmark it should be measured against, reachable in place.
Floorplan and acquisition debt, the equity call schedule, working capital and the cash conversion cycle, and the covenant tests the credit agreement applies. Covenant rows carry the basis being tested, because leverage measured one way passes while the other reads as a failure.
Levers for volume, debt draw, expense-to-gross, pay plans, and exit timing. Moving one re-runs the model rather than scaling a stored result, and each lever declares its units and range so an out-of-bounds input is reported instead of silently clamped into a different question.
A quality-of-earnings view separating reported profit from what survives diligence, and a decomposition of the projected return into its sources — operating improvement, deleveraging, and multiple — so the story a partner is told matches the arithmetic behind it.
A record per acquisition target with the broker package, the evaluation, the diligence state, and the modeled effect of adding that store to the group. Notes and activity live on the deal rather than in an inbox.
Agreements rendered from live data, sent for signature with an ESIGN-compliant disclosure, countersigned, and stored so the executed copy can be produced again intact. A material change to a document re-triggers consent; an editorial one does not.
Recurring lender and administrative PDFs scanned once, their fields mapped to data already in the system, and filled on demand rather than retyped.
A chat panel that answers over the live plan — reading the computed model, and re-running the engine for what-if questions — listing what it read and what it ran beneath each answer. It states plainly where a result cannot be computed instead of producing a plausible one.
Stakeholders — a capital partner, a lender, an OEM contact — see a curated set of pages: the plan, the schedule, what the money does, where the return comes from, and what is being asked for. They do not see the pipeline, the internal commentary, or the diligence detail that would start an argument before it has been asked for.
The routes a role may open are derived from the routes that role can see, from one definition. That closes the failure mode where a page is dropped from a menu but remains reachable by typing its URL — which looks like a security control and is not one. A build check verifies each page agrees with the policy, so the two cannot drift.
Every P&L line carries a definition and a benchmark, and every page carries a walkthrough explaining what it decides and what it is deliberately not claiming. None of that is optional: automated checks fail the build if a line has no definition, if a definition describes a line that no longer exists, if a page has no walkthrough, or if a walkthrough points at something that is no longer on the page.
Documentation that is merely intended goes stale within a quarter. Documentation the build refuses to ship without stays true, and it doubles as onboarding for a new manager.
Covenant tests are computed by the financial engine for the base case and the named scenarios, and are not derivable for an arbitrary user-defined run. Rather than extrapolating something that would look right, the system says which cases it can answer for and declines the rest — in the interface and in the assistant alike.
This is the whole trust argument. A dashboard is believed because of what it refuses to claim. One number that quietly guesses, discovered later, costs more credibility than a dozen honest blanks.
| Phase | Work |
|---|---|
| Weeks 1–3 | Assessment. Statement walkthrough, source inventory, and one written definition and benchmark per metric before any code. |
| Weeks 3–8 | Model and data layer. Store P&L through group consolidation, extracts running, reconciliation to the statement, and the consolidated dashboard live for a pilot group. |
| Weeks 8–14 | Departmental modules, balance sheet and working capital, and the scenario engine once the base numbers were accepted. |
| Weeks 12–18 | Execution modules: pipeline, target evaluation, documents with signature, forms automation. |
| Weeks 16–20 | Stakeholder role, generated deck and report, assistant panel, and the walkthroughs. Deployment and handover. |
About this page. This describes a real system and the decisions behind it. The store count and the phase dates reflect that build; your scope, your data sources, and your timeline will differ. We are describing an approach, not quoting a project.
No, and we would not build this for one. A single rooftop typically wants the consolidated dashboard, the departmental modules, and the data layer underneath them — roughly the first two phases. The capital, pipeline, and stakeholder machinery exists because a group raising money and buying stores needs it.
Yes, and for an operating group that is the normal configuration. The model computes from actuals loaded out of the DMS instead of from assumption files, and the scenario engine then runs forward from where the stores actually are. The forecast-driven setup described here reflects a platform being assembled, where much of the group did not exist yet.
The first release that people actually use is around week eight: the consolidated dashboard, reconciled to the statement, live for a pilot group. Everything after that is additive. We sequence it this way on purpose — a project whose first demo is in month five has usually built the wrong thing by then.
Less than most people expect. It runs a mid-tier model at medium effort because the work is bounded tool use over structured data rather than open-ended reasoning, and the whole conversation is cached rather than just the system prompt — so each round of a tool loop re-reads the context at roughly a tenth of the price. At dealership question volumes it is a small monthly line item.
You own the code, the data, and the infrastructure it runs on. It can be deployed into your cloud account. Nothing in the build is structured to make leaving difficult.
Whether you are running seven stores or buying your second, the hard part is the same: one set of numbers everyone agrees on. Let's talk about yours.
Schedule a Consultation
K Auto Tech