Automotive retail (multi-rooftop dealer group)Platform story
Four legacy apps became one platform for a 12-rooftop auto group.
A 12-rooftop auto group ran its people, paperwork and inventory across four separately deployed apps in three stacks, with no CI. We replaced them with one modular operations platform shipped through canary deploys, then earned our way into its inventory feeds, bank statements and dealer-management system, using AI where deterministic checks back it up.
- Engagement
- Client
- Client
- A 12-rooftop auto groupNamed only with written permission
- Sector
- Automotive retail (multi-rooftop dealer group)
- Story
- Platform
The number
The one figure we’ll stand behind.
Open the receipt for where it came from, how it was counted and when we last checked it. How we count
This platform is also where our documented delivery velocity comes from.
41
API modules in one operations platform, replacing four legacy apps
Retired along the way: ~349 legacy endpoints and ~130k lines of code across three stacks, none of it under CI.
receipt
SOURCE · Platform monorepo for a 12-rooftop auto group, plus the legacy-system inventory
METHOD · Module count from the API source tree; legacy figures from the pre-migration inventory.
VERIFIED · 2026-09
CLASS · repository
✓ every number on this site opens its receipt
CLAIM · platform-modules
How we count01 · Where they started
Four apps, three stacks, no CI
The group’s operations were spread across four separately deployed applications: an older FastAPI + Angular employee system with DocuSign, and the tools that grew up around it. Hundreds of endpoints, dozens of screens and more than eighty database tables ran without continuous integration, and inventory reconciliation lived in a manually maintained spreadsheet report.
- A legacy FastAPI + Angular employee system, plus three more apps
- Fourteen production scheduler jobs that had to keep running through the move
- A spreadsheet standing in for an inventory system of record
02 · The wall
Nothing could go down while it moved
Migrating a working business is harder than building a new one. Every scheduled job had to keep running through the cutover, every employee’s permissions had to survive intact, and the payroll-adjacent logic (timeclock, commissions, pay plans) could not be wrong for a single pay period. The group also needed room to grow: new stores, new domains, and a foundation that could one day serve other dealer groups.
03 · What we built
What we built.
Named systems, described by what they do, one part at a time.
Part 1: One modular platform, shipped like enterprise software
A single React 19 app over one Fastify 5 + Drizzle + Postgres API, organized as cleanly separable modules: RBAC with per-employee grants and revokes, timeclock, hiring and onboarding, HR requests and write-ups, DocuSign e-sign, commissions and pay plans, calendars, announcements and tasks, plus inventory, finance and fuel. It ships as four Cloud Run services through merge gates, no-traffic canary revisions, image-digest verification and explicit-revision rollback. Every new table carries an organization id, so the foundation is multi-tenant from the first migration.
- Permission overrides require a reason and land in a full audit trail
- Navigation is served by the API, never trusted from the client
- AI document intake reads factory invoices into the inventory pipeline
Part 2: Inventory matched across five systems that disagree
The spreadsheet became a system of record. Feeds from five incompatible dealer systems, plus manual files, normalize into one master vehicle record, matched by full VIN, partial VIN, stock number and factory order number with a confidence score. A configurable rules engine flags each discrepancy with a severity and a recommended action, and managers work the exceptions: assign, annotate, resolve. Every imported row is preserved verbatim for audit, and every import can be replayed.
- Scored VIN and stock-number matching
- Floor plan, alarms, recalls and aging tracked in one view
- A system-agnostic model: organization → dealership → source system
Part 3: Bank statements reconciled to the penny, and an accountant you can ask
Statements across the group’s accounts and legal entities are parsed by a deterministic decoder written for mainframe-generated PDFs, where off-the-shelf parsers corrupt the columns. Every statement must balance against its printed totals to the penny or it is quarantined for review. The language model handles only the genuinely fuzzy part, wrapped transaction descriptions, and must agree with the dates and amounts extracted deterministically. “Ask the Accountant” answers ownership’s questions in plain English through a SELECT-only database role and a two-layer SQL guard, and shows the SQL behind every answer.
- EBCDIC decoding built in-house; idempotent, content-hash-cached pipeline
- Tests prove the SQL guard rejects writes
- The AI can look; it cannot touch
Part 4: An integration that speaks the dealer’s decade
The group’s dealer-management system speaks 2000s-era SOAP with WS-Security. We built a client covering all six of its services, with typed operations generated from the vendor’s WSDLs, and verified read operations live against the staging environment. State-changing operations are refused by default and require explicit opt-in, with tests to prove it: write-safe by construction. A read-only testing dashboard renders validated forms for every operation, with writes disabled on the server.
- Standard-library-only Python runtime
- Certification documentation prepared for production access
- Accidental data changes blocked in code, not by policy
Part 5: Messaging built compliance-first
Transactional email runs through SendGrid behind an outbox with signed event webhooks, bounce and spam suppression that blocks future bulk sends, and one-click unsubscribe. For SMS, the A2P 10DLC registration, the consent text on screen and the stored consent record all read from one constant, with a test that fails if the wording drifts, and every consent lands in an append-only ledger kept for years.
- Append-only consent ledger with IP, timestamp and page URL
- TCPA- and CCPA-aware consent design
- A signed public unsubscribe page
04 · Screens withheld
A real client, so its screens stay private too.
This client is named only with written permission, and a screenshot would name it for us. The mockup above shows the shape of the system, never its data. The figures on this page are real, and every one opens to its receipt.
05 · More receipts
The supporting figures.
Same rule as the headline number: each one opens to its source, its method and the month we checked it.
~450
employees across ~12 rooftops, served by one platform
HR, hiring, e-sign, commissions, inventory and finance in a single system.
receipt
SOURCE · Employee records in the platform for a 12-rooftop auto group
METHOD · Active employee records at the time of the audit.
VERIFIED · 2026-09
CLASS · repository
✓ every number on this site opens its receipt
CLAIM · dealer-group-scale
How we count10 accounts · 9 entities
bank statements reconciled to the penny, every one checked against its printed totals
Beginning balance plus deposits, minus withdrawals, checks and fees, must equal the ending balance, or the statement is quarantined for review.
receipt
SOURCE · Finance pipeline repository for a 12-rooftop auto group
METHOD · Validation logic and database re-verification in the pipeline; failures are quarantined, never silently included.
VERIFIED · 2026-09
CLASS · repository
✓ every number on this site opens its receipt
CLAIM · penny-reconciliation
How we count116
operations in a dealer-management SOAP integration, write-safe by construction
State-changing operations are refused by default and need explicit opt-in, and tests prove it.
receipt
SOURCE · Integration client repository for a 12-rooftop auto group
METHOD · Operation registry generated from the vendor’s WSDLs across six services; read operations verified live against staging.
VERIFIED · 2026-09
CLASS · repository
✓ every number on this site opens its receipt
CLAIM · soap-operations
How we count