VettX Dashboard Concept

01 · The problem we explored

Profitable, and still hard to prove

Subscription software for vehicle dealerships follows a familiar pattern at scale. The business works. Proving that it works, quickly and to someone outside the company, is another matter.

Month-end numbers are assembled by hand in spreadsheets that feed the accounting system. Book profit and cash are reconciled after the fact rather than watched as they move. Accounts receivable (AR) ages quietly between reviews. Monthly recurring revenue (MRR) and customer lifetime value to customer acquisition cost (LTV:CAC) are real, but each figure has to be rebuilt before anyone can defend it.

Sales activity lives in a customer relationship management (CRM) tool, customer-success work in a second system, and product-usage data in a third. The three rarely agree, and nobody owns the reconciliation.

None of this stops a company from running well. It does make every serious question from an acquirer a research project. That raised the question DBAI set out to explore: what would an operator's screen look like if it were designed for an acquirer's eyes from day one?

02 · Design decisions

Two decisions that shaped everything else

An unverifiable number is not shown as a number

A plausible figure entered today is indistinguishable from a verified one a quarter later. So the prototype refuses to blur them. A financial figure with no recorded source is stored but never plotted, and its card reads “Source unverified.” A value nobody has is rendered as an em dash, never a zero and never an estimate. A modeled figure carries a “Modeled” badge wherever it appears.

Research proposes; a person decides

Automated research can change what the system knows, but it cannot change what the system concludes. A proposed change to a buyer's tier or scores, or a proposed new internal initiative, lands in an approvals queue with its previous value, proposed value, reason and evidence. Nothing moves until a person decides.

Both decisions trade speed for trust. In a sale process, a confident wrong number is more expensive than an honest blank.

03 · Tier 1

Operator Command Center

The command tier is where the day starts: where things stand, what is blocking progress, and what needs attention this week.

Command Center

Twelve indicator tiles include buyer counts by tier and by progress, stalled relationships, signed confidentiality agreements, management meetings, active diligence and days remaining to the configured horizon. Below them sit an exit-readiness score with its band and category bars, the top eight buyers by composite score, the top five open actions and a banner for pending approvals. Modeled figures on this screen carry the “Modeled” badge. When there is nothing to show, the screen says so: an empty actions list reads “No open tasks.”

Executive Mode

One screen, large type, no controls. It shows four headline tiles, the late critical milestones that are blocking the transaction, where the remaining gaps sit, and the five tasks that need attention this week. It reads the same queries as the Command Center rather than a separate summary, so the two cannot disagree.

Daily brief and alert engine

The war room composes a daily intelligence brief and a weekly strategic review from stored research. A scheduled sweep evaluates eighteen alert types against the records each day — buyer inactivity by tier, overdue follow-ups, late initiatives, deteriorating verified metrics, overdue diligence, incomplete data room sections, failed research runs and contradicted sources among them. Alerts are written as in-app notifications with a severity and are not repeated for thirty days. Their thresholds are displayed, read-only, in Settings.

Provider status and role-shaped navigation

Settings states whether research ran on live providers or on deterministic stand-ins (“Fully live” or “Partly mocked”), and research screens show which providers actually ran. Navigation is built from the same permission table that enforces access, so each role sees only the sections it may read.

Constrained AI features

Three features use a language model. The claim-extraction prompt forbids the model from stating, estimating or computing a valuation, revenue multiple or implied enterprise value for the company, and every claim must cite a source the run actually fetched. The transaction assistant answers only from the record context supplied with the question and never states a figure, date or name that is not in that context. Outreach drafting may not state or imply that the company is for sale, and may not invent metrics or customer names.

04 · Tier 2

Exit Command

Exit Command is not a CRM. It is a transaction operating system built around one loop.

1. Buyer signal
2. Strategic requirement
3. Internal development
4. Measurable improvement
5. Acquisition proof
6. Buyer engagement
7. Competitive tension
8. Better terms

A buyer signal that never reaches an initiative, and an initiative no buyer asked for, are both the loop broken. Initiatives are linked to the buyers they are meant to convince, with a proof statement on each link.

Six groups

Command

Command Center and Executive Mode.

Buyers

Buyer profiles, contacts, the deal pipeline, the relationship graph, outreach and meetings.

Value Creation

Internal development, exit readiness, financial performance, strategic metrics, modeled scenarios and tasks.

Transaction

Documents, the data room, diligence, term comparison, deal scenarios and the timeline.

Intelligence

Buyer intelligence, AI research, approvals and the war room, plus a competitor capability matrix and category thesis for roles that hold access.

System

Activity feed, a “How It Works” flow view, the data model and settings.

Acquirer universe

Buyers are tiered 1 to 3, with a watch list and a rejected list beside them. Each buyer carries seven scores on a 0–100 scale: six weighted dimensions — strategic fit, strategic synergy, acquisition appetite, financial capacity, transaction probability and engagement — and a channel-conflict score that is recorded but kept out of the composite. The weights are editable, and the weights used for each score are stored with it. Tier sets the research cadence: daily for Tier 1, weekly for Tier 2, monthly for Tier 3.

Pipeline and relationship graph

The pipeline has 26 stages, from target identification through closing, including three terminal stages. Each stage has its own stall threshold, and a buyer is flagged as stalled when the time since it entered the stage or was last contacted exceeds that threshold. The relationship graph finds the warmest route to a decision-maker, and the confidence of the whole route is the confidence of its weakest link.

Internal development and readiness

Initiatives sit on an impact and difficulty grid with four quadrants: Do Now, Strategic, Optional and Defer. Exit readiness is scored across 11 weighted categories and 49 checklist items, each scored by a person, and banded from Not ready to Ready.

Data room and diligence

The data room defines 16 sections and 54 mandatory document slots, each tracked as missing until filled; uploads go to private storage. Diligence reuses prior answers: when a new question resembles one already answered, the system surfaces the earlier answer with a similarity score and warnings for stale or mismatched material, and a person must confirm before it is reused.

Term comparison and scenarios

Proposed deal terms are compared on four bases: headline consideration, risk-adjusted, time-adjusted and expected proceeds. Contingent consideration is weighted only by a probability a person supplied; an earnout with no probability is excluded from every adjusted figure rather than assumed. A default time-discount rate applies until someone changes it, and it is shown on the screen.

Critical-path timeline

The timeline spans seven transaction phases. Milestones a person flags as critical are ranked by lateness, so the late items that matter most rise to the top.

Delta-first research

Research runs on Anthropic Claude for claim extraction and Tavily for search and page reading, through a sixteen-step pipeline. A scheduled run does not ask what is true about a buyer; it asks what changed since the last verified baseline, why it matters and what should happen next. Sources are graded A to D — filings and investor relations at A, established financial and trade media at B, interviews and professional profiles at C, aggregators, forums, social posts and unrecognized domains at D. The pipeline proposes and never applies.

Approvals and confidence

The approvals module is the only code that applies a proposal to a buyer's tier, scores, probability or modeled figure, a contact's decision authority, or an initiative's priority. Research runs and meeting debriefs can only propose. People can also edit those fields directly, and manual score edits are recorded in the same history. Two reviewers racing each other cannot double-apply a change, and every applied score change writes a history row tagged with its approval. Confidence only falls: a claim's confidence is the lowest of what was proposed, what its best source can support and what its class allows, so an inference cannot harden into a fact by being repeated.

Access

Eleven roles are defined in code: nine transaction roles from founder to read-only, a read-only demo visitor role, and one internal staff role with narrowly scoped access. Roles are read from Postgres on every request and checked by one server-side gate; a resource absent from a role's grants is denied.

05 · Design principles

What the system refuses to do

Provenance travels with evidence

Every research claim must carry a class — fact, inference, hypothesis or recommendation — and a graded source. Competitor facts carry a provenance tag: Your number, Mechanism, Open or Public source. Financial figures carry a verified flag and a source note, and modeled figures carry a “Modeled” badge.

Refusals as design

A missing figure renders as an em dash. A research run that finds nothing reports “NO MATERIAL CHANGE,” creates no tasks or proposals, and counts as a success — with its own tests. Term comparison holds no house view of an earnout.

One writer per fact

Proposals are applied only by the approvals module. An outreach message's sent timestamp has exactly one writer, and that writer transmits nothing: a person approves the draft, sends it themselves and records that they did.

Honest empty states

A screen with nothing to show says so. An empty financials page explains that nothing has been recorded, rather than filling the space with a convincing chart.

Deny by default

Adding a restricted resource grants it to nobody until it is listed. A user with no roles can do nothing.

06 · Working · Simulated · Planned

What runs today, what is staged, what is not built

Working runs in the code today. Simulated renders, but is driven by seed data or deterministic stand-ins. Planned is referenced but not coded. A row can carry more than one mark.

07 · Technical decisions

Stack, and the reasons behind it

Next.js on Vercel, Neon Postgres through the Drizzle schema toolkit, Anthropic Claude through Anthropic's commercial application programming interface (API), whose terms do not use API inputs for model training, and Tavily for search and page reading. Roles and grants live in Postgres and are enforced by a single server-side gate.

Why roles live in the database

A role read from a session token stays valid until the token expires. A role read from Postgres on every request is revoked the moment it is removed.

Why the model never writes the record

Model output becomes evidence records, drafts or proposals. It never changes a tier, score, priority or authority, and it never sends anything, because a person has to be able to say who authorized every consequential change.

Why provenance is enforced by the schema

Research claims cannot be stored without a class, and competitor records cannot be stored without a provenance tag. A rule enforced by the database survives the next feature; a rule enforced by habit does not.

Tests

516 unit tests across 20 files, all passing when run for this study, plus 74 end-to-end test cases across 8 files that require a seeded database and were counted rather than run. Many assert refusals: a read-only role cannot write, a resource absent from a role's grants is denied, a stand-in source is always graded D, a run that finds nothing reports no material change, confidence never rises across repeated runs, a settled proposal cannot be decided twice, an unapproved draft cannot be recorded as sent, and scheduled endpoints refuse an unauthenticated request.

Security posture: sign-in attempts are throttled per account and per network address in Postgres, and unknown accounts are throttled exactly like real ones. User actions that change records are written to an audit log with before and after states. Documents are stored privately, and scheduled endpoints refuse to run without a shared secret. DBAI does not currently hold System and Organization Controls 2 (SOC 2) certification; its posture is documented controls and a named release gate.

Ownership: DBAI's standard is that a commissioning client owns all code outright.

08 · Development process

How it was built

The repository history records commits from August 11 to August 16, 2026, with a demo-data update on September 10, 2026.

The build ran in four gates: foundation, authentication and roles, audit, buyer tracking and the pipeline; then internal development, readiness, meetings, outreach and approvals; then the transaction workspace — documents, the data room, diligence, term comparison, scenarios and the timeline; and finally AI research, the war room, alerts and scheduled jobs. Hardening followed, with login throttling, a public demo mode on fictional data and a competitor layer.

Claude Code was the build environment throughout. DBAI's delivery standard pairs two-person architecture review — Tim de Vallée and Kate Bless — with a release veto held by security and compliance.

09 · Intended benefits

What it is designed to make possible

These are intended outcomes, not measured results; this is a prototype on fictional data.

• An acquirer's question answered from one record instead of a week of reconciliation.
• Internal work tied to the buyers it is meant to convince, so the roadmap and the sale process move together.
• Figures that can be defended because their source and status travel with them.
• Research that surfaces change without silently rewriting conclusions.
• Access that can be revoked immediately and a history of who authorized each change.

10 · What a commissioned version would involve

From concept to operating system

1 · Foundation readiness

An assessment of the real data sources first: which systems hold which figures, how they are reconciled today, and which can be trusted.

2 · Connector build

Connectors to the accounting, customer-success, CRM and product-usage systems, carrying source and reconciliation status with every figure.

3 · Watchdog monitoring

Operator rules evaluated continuously against live data, run as a service.

4 · Buyer and value-creation layer

The Exit Command layer, built on top of a foundation whose numbers already hold.

11 · Team

Who built it

12 · Closing

See the concept, or talk about yours