LiveAuctioneers, Invaluable and HiBid all solve the same problem: a bidder wants one account and one place to search, while three thousand independent auction houses each want to keep running their own sales their own way. The aggregator sits between them.
That makes it a two-sided marketplace with a real-time component, which is a considerably harder build than a single-seller auction platform. Here is what it involves.
1. Catalogue ingestion is the first hard problem
Auction houses do not use your system. They use whatever back-office software they have used for fifteen years, and they will not change it for you. Your platform must accept their catalogue in whatever form it arrives:
- API integrations with the major auction management systems
- Structured file import — CSV, XML, and the specific export formats those systems produce
- Image ingestion at volume, with automatic resizing, format conversion and CDN distribution
- Field mapping tools so each house’s category names translate to your taxonomy
- Validation with clear error reporting, because the person uploading is a clerk, not a developer
Expect messy data. Lot numbers with letters, descriptions containing HTML from three generations of software, estimates as free text, images at wildly varying quality. Your ingestion layer needs to normalise all of it without rejecting the sale.
Onboarding friction here is the single biggest determinant of how fast you can grow supply. Every hour a house spends fighting your importer is an hour they spend reconsidering.
2. Live clerk integration
For live simulcast sales, the auctioneer is in a room calling lots, and a clerk is operating software that must drive your platform in real time. Online bidders need to see the current lot, the current price and the auctioneer’s state within a second.
What that requires:
- A clerking interface, or an integration with the house’s existing clerking software
- Persistent connections pushing lot and price state to every connected bidder
- Online bids surfacing to the clerk instantly and unmistakably
- A defined resolution path for a floor bid and an online bid arriving simultaneously — and the auctioneer’s decision is final, so the system must record it rather than arbitrate it
- Graceful degradation when the saleroom’s connection drops mid-sale, which it will
That last point is not hypothetical. Salerooms are often in old buildings with poor connectivity. The system must handle a thirty-second outage without losing the sale state.
3. Unified bidder identity across sellers
The core value to a bidder is one account for everything. The complication is that each auction house has its own terms, its own premium, its own payment window and its own view on who they will accept as a bidder.
So you need per-house bidder approval — a bidder registered on your platform still requires approval to bid in a specific sale — with credit references, deposit requirements and approval history tracked per house. Houses also need the ability to block individual bidders, and that block must be theirs alone rather than platform-wide.
4. Premium, tax and settlement complexity
This is where the accounting gets genuinely difficult. Each house sets its own buyer’s premium, you add your own online surcharge on top, and tax treatment varies by the house’s jurisdiction, the buyer’s jurisdiction and the item category.
The invoice a buyer receives after winning lots from three different houses in one week must be either three correct invoices or one correctly aggregated one — and either way the money must split correctly between each house and you. Get this wrong and you have an accounting problem across thousands of counterparties.
Build the fee engine as configurable rules per seller from the start. Hardcoding premium logic is the mistake that forces a rewrite. Background on the mechanics is in what a buyer’s premium is.
5. Search is your actual product
A bidder comes to an aggregator to find things. With hundreds of thousands of live lots across thousands of sales, search quality is what differentiates you from a directory.
That means a real search engine with faceting by category, price, location, sale date and house; saved searches with alerts, which is the single most effective retention feature in this category; image search and visual similarity; and normalisation of the inconsistent category names arriving from every house.
6. The cold start problem
The commercial reality: bidders come for lots, and houses come for bidders. Starting both from zero is the hardest problem in the build, and it is not a technical one.
What works is starting narrow. Pick one category and one region, sign enough houses to make search worthwhile in that slice, and become genuinely the best place to find that specific thing. Breadth comes later. Aggregators that launch broad end up thin everywhere, and thin is indistinguishable from empty.
7. Build versus license
The bidding engine, invoicing and payments are commodity — license them. Your engineering budget belongs in ingestion tooling, search and the clerking integration, because those determine whether houses will use you and whether bidders will stay.
The alternative worth considering, incidentally, is not building an aggregator at all. Many houses now run their own auctioneer software and treat aggregators as a marketing channel — a shift covered in Proxibid alternatives.
Frequently asked questions
How do aggregators make money?
An online buyer’s premium surcharge on top of the house’s own premium, sometimes with a listing or subscription fee to the house as well.
What is the hardest part of the build?
Catalogue ingestion from heterogeneous sources, followed by live clerk synchronisation. Neither is glamorous and both determine whether the product works.
Is there room for new aggregators?
In specific underserved categories and regions, yes. General aggregation is well covered. Talk to our team about niche viability.
