Case study · Auto brokerage and leasing
A Custom CRM for an Auto Brokerage, Built in Weeks Instead of Quarters
How American Auto Group, an auto brokerage in Staten Island, New York, got a CRM built around vehicle deals, dealer relationships and credit applications, with Social Security numbers encrypted at rest and masked in the interface. Built on the WallFlow core, delivered under a Data Processing Agreement.
A common objection to custom software is that it takes too long and costs too much for a small business. This is the counterexample: a working CRM for an auto brokerage, built around a business that has nothing in common with wallpaper installation, shipped in weeks rather than quarters. This page describes what was built, why it was fast, and how the sensitive data is handled.
The client is named here with their written permission. The work is governed by a Data Processing Agreement in which the client is the data controller. The system is in daily use by their team, and every technical detail below describes what is actually built rather than what is planned.
The problem: no dealer CRM fits a brokerage
An auto broker sits between the customer and the dealer. They are not selling from their own lot, so dealership DMS software does not describe their work. They are not running a simple sales funnel either, so a generic CRM does not either. The actual unit of work is a deal that has a customer, a target vehicle, one or more dealers being worked in parallel, a credit application, and a stack of documents that must be collected in a particular order.
Before the build, that lived across a spreadsheet, a shared inbox, and a lot of memory. The failure mode was not dramatic. It was a deal quietly stalling because nobody could see that the credit application had come back three days ago.
What was built
- •A deal pipeline with the brokerage's real stages, not a generic lead-to-won funnel
- •Client records with the documents each deal requires, tracked as collected or outstanding
- •Dealer records, so the same dealer relationship is visible across every deal it touches
- •A public credit application the customer fills in themselves, including a photo of their licence, a drawn signature, and an optional co-applicant
- •Lender packages generated as PDFs, with the Social Security number masked by default
- •Role-based access, so a salesperson sees their deals and an owner sees everything
- •A financial view: what is in flight, what closed, what is still owed, plus payout splits across brokers
- •A tenant theme in the client's own brand colours, and a public marketing site on the same deployment
Why it shipped in weeks
The build did not start from an empty repository. It started from the WallFlow core, which is a production system already solving the parts of any business application that are slow and unglamorous: authentication, company and branch isolation, role-based permissions, PDF generation with custom branding, e-signature, file storage, Stripe billing, email and Telegram notifications, and scheduled background jobs.
None of that had to be designed, written, or debugged again. The custom work was the part that is actually specific to auto brokerage: the deal model, the dealer relationships, the credit application flow, and the encryption around it. That ratio is the whole argument for this approach. Most of a business application is not your business; it is the same twenty problems every business application has.
The visual identity was handled with the same bias toward evidence. Rather than asking the client to pick a colour, the existing company website was measured: every colour was counted by the share of pixel area it occupied, which surfaced the red that actually carried the brand. That value became the tenant theme, and it now drives the interface, the documents, and the client-facing site.
Handling Social Security numbers
A credit application means Social Security numbers, and that changes the engineering requirements. A small business cannot casually hold that data in a spreadsheet. The controls that shipped:
- •Encrypted at rest with AES-256-GCM, so the raw value is not readable from the database directly
- •Masked in the interface, so day-to-day staff see only the last four digits and never the full number
- •Fail-closed intake: if the encryption key is unavailable, the application form refuses the submission rather than storing a Social Security number in the clear
- •Row-level security, so a record is only reachable by the company that owns it, enforced by the database rather than by application code that could be bypassed
- •Audit logging before disclosure, not after: revealing a number or downloading a lender package writes the audit record first, and the download is blocked if that write fails
- •Financial masking at the API layer, so roles that should not see profit figures do not receive them over the network at all
- •Private document storage, with files served through expiring signed links instead of public URLs
- •Two-factor authentication available on accounts
One limit stated plainly: the encryption key is held in the application's server environment, which means the operator can decrypt. A build where the client holds the key and the developer genuinely cannot read the data is possible and is a larger piece of work. Anyone who tells you encryption alone means they cannot see your data is describing a different architecture than the one they built.
If you are being quoted for a custom system that will hold Social Security numbers, payment details, or medical information, ask specifically about encryption at rest, interface masking, row-level isolation, audit logging, and whether documents sit behind signed links. If the answer is vague, that is the answer.
The website is part of the system, not a separate purchase
The brokerage's public website runs from the same deployment as the CRM, and the two are wired together in both directions. Offers are authored inside the CRM: adding a promotion with a photo, a price and lease terms puts it on the public specials page within minutes, with no developer and no redeploy. In the other direction, the enquiry button on each offer carries that offer's own identifier, so when a visitor asks about a specific car the lead arrives in the CRM already attached to it rather than as an anonymous 'interested in a vehicle' message.
That closes a loop most small businesses never close, because their website and their CRM come from different suppliers and know nothing about each other. Here the site is the front end of the CRM: it publishes what the CRM says is on offer, and it feeds back what the public asked for. Credit applications submitted on the site follow the same path, arriving with the Social Security number already encrypted and converting into pipeline deals.
Who owns what
The database and hosting accounts are registered to the client and billed to the client. The work is governed by a written Data Processing Agreement in which the client is the data controller. If the relationship ends, the system keeps running and the data stays with the business that owns it. This is deliberately the opposite of the arrangement where an agency holds the keys and the client rents access to their own operation.
What this means if you are considering a custom build
The transferable lesson is not that auto brokerage is special. It is that the distance between two service businesses is smaller than it looks. Wallpaper installation and vehicle brokerage share a shape: work arrives, gets quoted, moves through stages, involves documents and signatures, and ends in an invoice. The specific vocabulary and the specific math differ. Everything underneath is the same problem, already solved.
That is why a custom system for a small service business should be measured in weeks and low five figures, not quarters and six figures. If the quote you are looking at assumes everything is built from scratch, ask what is being reused.
Scope, process, and what it costs. Or message Eugene directly.
Want the same for your business?
The discovery call maps how work actually moves through your company. You keep the map either way.
See what a custom build involves →