Back in 2021, a client came to me with what sounded like a straightforward brief: "We need an auction site. Like eBay, but niche — classic motorcycle parts." Three months, two abandoned prototypes, and one genuinely embarrassing production outage later, I had opinions. Strong ones. We got there in the end, but I wouldn't build it the same way now. Not even close.
Auction platforms are deceptively hard. On the surface it's just listings, bids, and a timer. But the moment two users bid within milliseconds of each other, or your WebSocket connection drops right as the countdown hits zero, or your payment processor times out mid-capture — suddenly you're explaining to a very angry seller why their 1967 BSA Lightning went for £12. So let me walk you through what I'd actually build in 2026, tool by tool, decision by decision.
---
The Core Architecture Decision: Monolith or Services?
Don't let anyone sell you on microservices for a first version. I mean it.
I've seen this mistake repeatedly — founder hires a consultant, consultant diagrams out eight separate services on a whiteboard, everyone nods, and six months later nothing ships because the team is debugging inter-service latency on a platform with 40 users. For an auction MVP or even a moderately scaled product (say, under 50,000 monthly active users), amodular monolithis the right call.
What I'd reach for:Next.json the frontend and API layer, with a Node.js backend. Not because it's trendy. Because the server components model in Next.js 14+ genuinely reduces the complexity of auction listing pages where SEO actually matters — you want those lot descriptions indexed. The API routes handle lighter lifting; the heavy real-time stuff lives elsewhere (more on that in a moment).
Database? PostgreSQL. Always PostgreSQL for anything transactional. Auctions are deeply relational — users, lots, bids, reserves, invoices — and you want foreign key constraints doing real work, not vibes-based application logic. I'd run it onSupabasein 2026 because you get Postgres, row-level security, and a real-time subscription layer baked in, which collapses what used to be three separate infrastructure concerns into one bill.
---
Real-Time Bidding: The Part That'll Break You
This is where most auction platforms die. Or at least limp.
The fundamental problem: bidding has to feel instant, has to be consistent, and has to handle race conditions correctly. If two users submit a bid at the same millisecond, one of them wins. The database decides who. Not the frontend, not the load balancer — the database, via a properly written transaction withSELECT FOR UPDATE.
For the real-time layer itself, I'd useAblyin 2026 rather than rolling raw WebSockets. I tried the raw approach on a property auction project at Seahawk back in 2022 — self-hosted socket.io, Redis pub/sub, the works. It was fine until it wasn't. Ably gives you guaranteed message ordering, connection state recovery (so if a bidder's phone switches from WiFi to 4G mid-auction, they don't silently miss the winning bid), and a sensible dashboard. The pricing at scale is real, but for most auction operators it's noise compared to infrastructure complexity.
Handling the "Bid Sniping" Problem
Auction sniping — placing a bid in the last few seconds — is either a feature or a bug depending on your client. eBay famously allows it. Many specialist auction houses extend the timer by 30–60 seconds if a bid arrives in the final minute. This is called "soft close" or "anti-sniping" logic. Build it from day one. The rule is simple:
- Bid arrives with less than N seconds remaining
- Transaction confirms the bid is valid and highest
- Auction end time extends by N seconds
- New end time broadcasts to all connected clients via Ably
It's maybe 40 lines of server logic. Skipping it and bolting it on later is a headache you don't want.
---
Payments: Don't Get Clever
I've seen people reach for exotic payment setups on auction sites because auctions have quirky requirements — you capture payment details upfront, only charge when the lot closes, might need to hold a deposit, might need to refund immediately if outbid. All true. All solvable with Stripe without leaving the Stripe docs.
Stripein 2026 is still the right answer for the vast majority of auction operators. Specifically:
- Stripe Payment Intentsfor the standard bid-to-charge flow
capture_method: manualto authorise a card without charging it (essential for deposit holds)- Stripe Connect if you're building a marketplace where multiple sellers receive payouts
The one thing I'd flag: don't authorise cards for the full lot value upfront unless you have legal advice saying you must. Authorise for a deposit (10–25% is common in the auction world), then capture or void once the lot closes. Your card decline rates will thank you.
For higher-value auction houses — classic cars, fine art, that sort of thing — you'll want to accommodate bank transfer. Stripe now handles this reasonably well via their payment link and invoice products, but you'll still need a human in the loop for reconciliation. Build a simple admin queue for it; don't automate what doesn't need automating.
---
Search and Filtering: Typesense, Not Elasticsearch
Honestly, the search question on auction platforms is underrated. Users need to filter by category, current price, time remaining, condition, location. They need it fast.
Elasticsearch is overkill for most auction sites and a genuine pain to operate.Typesenseis what I'd use. It's open source, you can self-host on a $6 DigitalOcean droplet or use Typesense Cloud, and the search quality is excellent for catalogue-style data. Sync your PostgreSQL lots table to Typesense via a simple change-data-capture hook or a cron job every 30 seconds (real-time sync of auction lot prices is nice but rarely necessary for search).
The one thing Typesense doesn't handle well out of the box: geosearch for collection-only items. It does have geo filtering, but if your auction site has heavy "local pickup only" inventory, spend half a day on that configuration early. I didn't, on a garden machinery auction site in 2023, and we retrofitted it later at twice the effort.
---
Infra and Hosting
Here's my 2026 default:
- Vercelfor the Next.js frontend and API routes — zero config deployments, preview URLs per branch, edge functions where needed
- Supabasefor PostgreSQL and auth
- Ablyfor WebSockets
- Typesense Cloudfor search
- Cloudflarein front of everything — free tier handles DDoS, image optimisation, and caching without fuss
- UploadcareorCloudinaryfor seller-uploaded lot images (never store user uploads on your own server in 2026, please)
That stack has no Kubernetes, no self-managed Redis cluster, no DevOps hire. A solo developer or small team can run it. And critically — it scales without re-architecting. Vercel and Supabase will handle the traffic spike when you get featured in a trade publication and 8,000 people hit your site in an hour.
One Infrastructure Mistake I Keep Seeing
People forget background jobs. Auction close events aren't user-triggered — they happen at a specific timestamp, server-side. You need a reliable job scheduler. I'd useInngestfor this in 2026. It handles time-based triggers, retries, and gives you an event log that's actually useful when you're debugging "why did lot 447 close without sending the winner email". Don't use a simplecronon your server. When your server restarts, your cron state is gone.
---
Admin and Seller Tools
Sellers need to create listings, upload images, set reserve prices, and view bid histories. Buyers need watchlists, bid alerts, and invoice downloads. These are not glamorous features. They are the ones clients call you about at 9pm on a Thursday.
For the admin panel, I'd build lightly on top ofRetoolor a custom Next.js dashboard depending on budget. Retool is genuinely fast to stand up and handles the 80% of auction admin tasks — approving listings, managing users, voiding bids — without writing much code. For anything client-facing I'd build properly in Next.js, because Retool embedded in an iframe is not a good user experience.
Email notifications — outbid alerts, lot closing soon, invoice ready — go throughResendin 2026. It replaced SendGrid in my stack about 18 months ago and I haven't looked back. The developer experience is notably better and the deliverability has been solid.
---
Security Considerations Specific to Auctions
Auction platforms attract bid manipulation attempts. Shill bidding (a seller driving up their own lot's price using fake accounts), account takeovers to place fraudulent winning bids, and payment fraud are all real and disproportionately common compared to typical e-commerce.
A few things I'd bake in from the start:
- Rate limiting on bid submission— max N bids per user per minute per lot, enforced at the API layer. Upstash Redis is good for this; it has a purpose-built rate limiting library.
- Email verification before bidding is allowed— sounds obvious, stops a surprising amount of abuse
- Fraud scoring via Stripe Radar— already included in Stripe, just use it
- IP and device fingerprinting for suspicious account clusters—FingerprintJS Prois worth the cost if you're operating at any meaningful scale
Honestly, the most important thing is logging. Log every bid attempt, every failed payment, every account action. When something goes wrong — and it will — you want a complete audit trail. Supabase's built-in logging plus a lightweight setup onAxiomcovers this without much effort.
---
FAQ
What's the minimum viable stack for a small, local auction site?
If you're building for a local auction house with maybe 200 users and weekly sales, you don't need Ably or Typesense. WordPress with a plugin likeAuctions for WooCommercegets you surprisingly far. I've set up three of these for regional auction houses — antiques, farm equipment, that sort of thing. The moment you need real-time competitive bidding under load, outgrow it fast.
Can I use Firebase instead of Supabase?
You can. Firebase's Firestore is actually a reasonable fit for real-time bid state. The reason I prefer Supabase in 2026 is SQL — auction data has a lot of relational structure (lots belong to sales, bids belong to lots and users, invoices reference bids), and querying a document database for that gets messy. But if your team already knows Firebase deeply, don't switch for the sake of it.
How do I handle time zones for auction end times?
Store everything in UTC. Always. Display in the user's local time zone via the browser. This sounds obvious and I still see it done wrong on roughly one in five projects. TheIntl.DateTimeFormatAPI in modern browsers handles the display side without any library.
Do I need a mobile app?
Not for an MVP. A well-built progressive web app with push notifications (via the Web Push API) covers 90% of what bidders actually need on mobile. Native apps come later, if the business warrants it. I'd useExpoandReact Nativewhen that day arrives — shared codebase across iOS and Android, and the team already knows React.
---
Running auctions online is a legitimate engineering challenge dressed up in a deceptively simple UI. The bidding interface is three buttons and a number. Everything underneath it — consistency, fairness, real-time state, fraud prevention — is where the actual work lives. Get the stack right from the start and the rest is just features. Get it wrong and you're the person explaining to a seller why their lot sold for £12.
Build boring infrastructure. Build interesting products on top of it.