Back to Main PageAn auction account management platform for a US car auction and shipping broker. One master account on Copart and IAA, many customers — each with their own controlled access, and every bid, save, and won lot attributed automatically.
This case study focuses on the delivery constraints, product choices, and workflow decisions that shaped the build.
Broker platform
US car auctions and shipping
Copart and IAA
Let a broker put customers in front of Copart and IAA inventory without ever handing over the master credentials that the whole business depends on.
One auction identity, many buyers acting through it. Every action has to be traceable to the customer who took it, and every customer has to be limited to what the broker allowed.
A broker portal where customer access, bidding activity, and attribution are one system: give access, watch it used, and know exactly whose lot it is when it wins.
Buying at a US salvage auction is not something a member of the public does directly. Copart and IAA sell through licensed accounts, so a broker's master credentials are the business — and the moment they are shared with a customer, the broker has lost both control and the record of who did what.
Bidque is the layer that removes that trade-off. The broker keeps one master account; every customer gets their own controlled way in.
The core idea is delegation without disclosure. Each customer is issued their own access to Copart and IAA inventory through the broker's account, with the master credentials never leaving the broker's side. Access is granted, scoped, and withdrawn from the broker's console rather than by changing a shared password and re-distributing it.
For the broker that turns a standing risk into an ordinary administrative task: onboarding a new buyer no longer means widening the circle of people who hold the keys to the business.
Every bid, every saved lot, and every win is tied to the customer who caused it, automatically, at the moment it happens. There is no reconciliation step at the end of the day and no spreadsheet mapping lot numbers back to buyers.
That matters most when a lot is won: the broker knows immediately whose vehicle it is, who is invoiced, and where it ships — which is the point at which a shared account normally becomes an argument.
Each customer carries a complete activity history rather than a current state. What was bid, on which lot, at what time, and what came of it stays on the record.
The log is what makes delegated access defensible. A dispute about a bid, a limit, or a win is settled by reading the history instead of by recollection, and the broker can review a customer's behaviour before deciding whether to extend their access.
Brokers sign in to an admin console that keeps customer accounts, their access, and their auction activity in one place, with a persistent session option so that daily operational use does not mean re-authenticating constantly.
The console is deliberately the only place where the sensitive operations live — issuing access, adjusting it, and revoking it — so the security surface of the whole platform is one screen with one audience.
The client's business does not end at the hammer: won vehicles have to be collected, shipped, and delivered to the buyer. Because attribution is established at the moment of the bid, the handover from auction to logistics starts with the customer already attached to the vehicle.
That is the practical argument for building the auction side and the customer side as one product rather than two: the information that logistics needs is created upstream, as a by-product of bidding, instead of being re-entered afterwards.
The platform is a multi-tenant web application: one broker identity, many customer identities beneath it, and a permission model that decides what each of them may do with the auction accounts the broker controls. Activity logging is not a reporting feature bolted on afterwards — it is written at the same moment as the action it describes, which is what makes attribution trustworthy.
If you are scoping a marketplace, customer portal, or workflow-heavy MVP, start with the smallest transaction that proves the business works. Then estimate the cost, compare custom code against no-code, and decide which features belong in version one.
Because the account is the licence to trade. A shared password gives every customer the ability to act as the broker, removes any record of who did what, and cannot be withdrawn from one person without disrupting everyone. Delegated access solves all three at once.
Attribution has to be captured at the moment of the action, not reconstructed from it. If bids are placed through a shared identity, the information about who placed them never existed and no amount of later reporting can recover it. That is why it is a foundation, not a feature.
Both, and that is the interesting part. The broker uses it as an internal console for managing customers and access, while customers experience it as the product through which they buy. One system, two audiences, one permission model.
Yes. The pattern — one privileged upstream identity, many downstream users, scoped access, and complete attribution — recurs across brokerage, procurement, agency, and reseller businesses. The fastest next step is to estimate the scope.
Book a free founder call. We'll help you figure out what to build first, what it'll cost, and how fast we can launch it.
Limited availability — email alex@shipkit.us or use the contact page to start the conversation.
