2021 kam ein Mandant zu mir mit einem Brief, der ziemlich geradlinig klang: „Wir brauchen eine Auktionsseite. Wie eBay, aber Nische — Klassiker-Motorradteile." Drei Monate, zwei abgebrochene Prototypen und ein wirklich peinlicher Produktionsausfall später hatte ich eine Meinung. Eine starke. Am Ende haben wir es geschafft, aber ich würde es jetzt nicht gleich bauen. Nicht im Geringsten.
Auktionsplattformen sind täuschend schwierig. An der Oberfläche sind es nur Inserate, Gebote und ein Timer. Aber sobald zwei Nutzer Millisekunden voneinander entfernt bieten, oder deine WebSocket-Verbindung bricht genau ab, wenn der Countdown auf Null geht, oder dein Zahlungsdienstleister bricht mitten im Erfassen ab — plötzlich musst du einem sehr wütenden Verkäufer erklären, warum seine 1967er BSA Lightning für £12 verkauft wurde. Also lass mich dir durchgehen, was ich 2026 wirklich bauen würde, Tool für Tool, Entscheidung für Entscheidung.
---
Die Kern-Architektur-Entscheidung: Monolith oder Services?
Lass dich nicht von niemandem in Microservices für eine erste Version reinreden. Ich meine es ernst.
Ich habe diesen Fehler wiederholt gesehen — Gründer stellt einen Berater ein, Berater zeichnet acht separate Services auf ein Whiteboard, alle nicken, und sechs Monate später shipped nichts, weil das Team Inter-Service-Latenz auf einer Plattform mit 40 Usern debuggt. Für ein Auktions-MVP oder sogar ein mäßig skaliertes Produkt (sagen wir, unter 50.000 monatlich aktiven Usern) ist ein modularer Monolith der richtige Weg.modular monolithis the right call.
Was ich greifen würde: Next.js für Frontend und API-Layer, mit einem Node.js-Backend. Nicht weil es trendy ist. Weil das Server-Components-Modell in Next.js 14+ die Komplexität von Auktionslistenseiten, bei denen SEO wirklich zählt, deutlich reduziert — man möchte, dass die Losbeschreibungen indexiert werden. Die API-Routes übernehmen die leichteren Aufgaben; das schwere Echtzeit-Stuff lebt anderswo (gleich mehr dazu).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).
Datenbank? PostgreSQL. Immer PostgreSQL für alles Transaktionale. Auktionen sind zutiefst relational — User, Lose, Gebote, Reserven, Rechnungen — und man möchte, dass Foreign-Key-Constraints echte Arbeit leisten, nicht vibes-basierte Application-Logik. Ich würde es 2026 auf Supabase laufen lassen, weil man Postgres, Row-Level-Security und einen Echtzeit-Subscription-Layer bekommt, was früher drei separate Infrastruktur-Concerns waren, jetzt in eine Rechnung zusammengefasst.Supabasein 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.
---
Echtzeit-Bidding: Der Teil, der dich zum Scheitern bringt
Hier sterben die meisten Auktionsplattformen. Oder zumindest hinken sie.
Das Grundproblem: Bieten muss sich sofort anfühlen, muss konsistent sein und muss Race Conditions korrekt handhaben. Wenn zwei User zur gleichen Millisekunde ein Gebot abgeben, gewinnt einer. Die Datenbank entscheidet, wer. Nicht das Frontend, nicht der Load Balancer — die Datenbank, über eine korrekt geschriebene Transaction mit SELECT FOR UPDATE.SELECT FOR UPDATE.
Für den Echtzeit-Layer selbst würde ich 2026 Ably nutzen statt rohe WebSockets zu bauen. Ich habe den Raw-Ansatz bei einem Property-Auktionsprojekt bei Seahawk 2022 versucht — selbst gehosteter socket.io, Redis pub/sub, alles. Es war okay, bis es nicht mehr okay war. Ably gibt dir garantierte Message-Ordering, Connection-State-Recovery (also wenn das Telefon eines Bieters während einer Auktion von WiFi zu 4G wechselt, verpassen sie nicht stumm das Gewinnergebot), und ein vernünftiges Dashboard. Die Pricing im großen Maßstab ist real, aber für die meisten Auktionsbetreiber ist es Kleinkram im Vergleich zu Infrastruktur-Komplexität.Ablyin 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.
Mit dem „Bid-Sniping"-Problem umgehen
Auction-Sniping — ein Gebot in den letzten Sekunden abgeben — ist je nach Client entweder ein Feature oder ein Bug. eBay erlaubt es bekanntlich. Viele spezialisierte Auktionshäuser verlängern den Timer um 30–60 Sekunden, wenn ein Gebot in der letzten Minute kommt. Das wird „Soft Close" oder „Anti-Sniping"-Logik genannt. Baue es von Tag eins ein. Die Regel ist einfach:
- Gebot trifft mit weniger als N Sekunden verbleibend ein
- Transaktion bestätigt, dass das Gebot gültig und das höchste ist
- Auktionsendzeit verlängert sich um N Sekunden
- Neue Endzeit wird über Ably an alle verbundenen Clients übertragen
Es sind vielleicht 40 Zeilen Server-Logik. Das zu überspringen und später anzubringen ist ein Ärgernis, das du nicht haben willst.
---
Zahlungen: Werde nicht zu clever
Ich habe gesehen, dass Leute bei Auktionsseiten zu exotischen Zahlungslösungen greifen, weil Auktionen knifflige Anforderungen haben — du erfasst Zahlungsdetails im Voraus, belastest erst, wenn das Los schließt, möchtest vielleicht eine Kaution halten, möchtest vielleicht sofort erstatten, wenn überboten wird. Alles wahr. Alles lösbar mit Stripe, ohne die Stripe-Dokumentation zu verlassen.
Stripe im Jahr 2026 ist immer noch die richtige Antwort für die überwiegende Mehrheit der Auktionsbetreiber. Speziell:in 2026 is still the right answer for the vast majority of auction operators. Specifically:
- Stripe Payment Intents für den Standard-Gebot-zum-Laden-Ablauffor the standard bid-to-charge flow
capture_method: manuell zum Autorisieren einer Karte ohne Belastung (essentiell für Hinterlegungen)to authorise a card without charging it (essential for deposit holds)- Stripe Connect, wenn Sie einen Marktplatz aufbauen, auf dem mehrere Verkäufer Auszahlungen erhalten
Das eine, das ich flaggen würde: Autorisieren Sie Karten nicht für den vollen Lotwert im Voraus, es sei denn, Sie haben rechtliche Beratung, die besagt, dass Sie müssen. Autorisieren Sie für eine Kaution (10–25 % ist üblich in der Auktionswelt), dann erfassen oder annullieren Sie, sobald das Los schließt. Ihre Kartablehnungsquoten werden es Ihnen danken.
Für höherwertige Auktionshäuser – Oldtimer, Kunstgegenstände, solche Dinge – sollten Sie Banküberweisung unterstützen. Stripe handhabt dies mittlerweile anständig über ihre Payment Link und Invoice Produkte, aber Sie benötigen noch immer einen Menschen im Prozess für die Abstimmung. Erstellen Sie eine einfache Admin-Warteschlange dafür; automatisieren Sie nicht, was keine Automatisierung braucht.
---
Suche und Filterung: Typesense, nicht Elasticsearch
Ehrlich gesagt, die Suchfrage auf Auktionsplattformen wird unterschätzt. Benutzer müssen nach Kategorie, aktuellem Preis, verbleibender Zeit, Zustand, Standort filtern. Sie brauchen es schnell.
Elasticsearch ist für die meisten Auktionsseiten Overkill und ein echtes Problem zu betreiben. Typesense würde ich verwenden. Es ist Open Source, Sie können es selbst auf einem 6-Dollar-DigitalOcean-Droplet hosten oder Typesense Cloud verwenden, und die Suchqualität ist hervorragend für katalogähnliche Daten. Synchronisieren Sie Ihre PostgreSQL-Lotstabelle mit Typesense über einen einfachen Change-Data-Capture-Hook oder einen Cron-Job alle 30 Sekunden (Live-Synchronisierung von Auktionslospreisen ist nett, aber selten notwendig für die Suche).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).
Das eine, das Typesense out of the box nicht gut handhabt: Geosuche für Nur-Abholung-Artikel. Es hat Geofilterung, aber wenn Ihre Auktionsseite viel „nur lokale Abholung"-Inventar hat, wenden Sie halben Tag dafür auf diese Konfiguration früh auf. Ich habe es nicht getan, auf einer Gartenmaschinen-Auktionsseite im Jahr 2023, und wir haben es später mit doppeltem Aufwand nachgerüstet.
---
Infrastruktur und Hosting
Das ist mein Standard für 2026:
- Vercel für das Next.js Frontend und API Routes — Zero-Config Deployments, Preview URLs pro Branch, Edge Functions wo nötigfor the Next.js frontend and API routes — zero config deployments, preview URLs per branch, edge functions where needed
- Supabase für PostgreSQL und Authfor PostgreSQL and auth
- Ably für WebSocketsfor WebSockets
- Typesense Cloud für die Suchefor search
- Cloudflare vor allem — der kostenlose Plan handhabt DDoS, Bildoptimierung und Caching ohne Umschweifein front of everything — free tier handles DDoS, image optimisation, and caching without fuss
- Uploadcare oder Cloudinary für von Verkäufern hochgeladene Lotbilder (speichert in 2026 bitte keine Nutzer-Uploads auf deinem eigenen Server)orCloudinaryfor seller-uploaded lot images (never store user uploads on your own server in 2026, please)
Dieser Stack benötigt kein Kubernetes, keinen selbstverwalteten Redis-Cluster, keine DevOps-Hire. Ein Solo-Developer oder kleines Team kann ihn betreiben. Und kritisch — er skaliert ohne Neuarchitektur. Vercel und Supabase werden den Traffic-Spike handhaben, wenn deine Site in einer Fachpublikation erwähnt wird und 8.000 Menschen in einer Stunde auf deine Seite kommen.
Ein Infrastruktur-Fehler, den ich immer wieder sehe
Menschen vergessen Background Jobs. Auktionsschluss-Events werden nicht vom Benutzer ausgelöst — sie finden zu einem bestimmten Zeitstempel auf dem Server statt. Du brauchst einen zuverlässigen Job Scheduler. Ich würde 2026 Inngest dafür verwenden. Es behandelt zeitgesteuerte Trigger, Retries und gibt dir ein Event Log, das tatsächlich nützlich ist, wenn du debuggst, „warum ist Lot 447 ohne eine Gewinner-E-Mail geschlossen worden". Verwende keinen einfachen Cron auf deinem Server. Wenn dein Server neu startet, ist dein Cron-Status weg.Inngestfor 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- und Seller-Tools
Seller müssen Angebote erstellen, Bilder hochladen, Mindestgebote setzen und Gebotshistorien ansehen. Käufer benötigen Merklisten, Gebotsalarme und Rechnungsdownloads. Das sind keine glamourösen Features. Das sind die, bei denen dich Kunden um 21 Uhr an einem Donnerstag anrufen.
Für das Admin-Panel würde ich leicht auf Retool oder ein benutzerdefiniertes Next.js Dashboard aufbauen, je nach Budget. Retool ist wirklich schnell einsatzbereit und behandelt 80 % der Auktionsadmin-Aufgaben — Angebote genehmigen, Benutzer verwalten, Gebote stornieren — ohne viel Code zu schreiben. Für etwas für Kunden würde ich richtig in Next.js bauen, weil Retool in einem iframe ist keine gute Benutzererfahrung.Retoolor 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.
E-Mail-Benachrichtigungen — Überboten-Benachrichtigungen, Lot schließt bald, Rechnung bereit — laufen 2026 über Resend. Es hat SendGrid vor etwa 18 Monaten in meinem Stack ersetzt und ich habe nicht zurückgeschaut. Die Developer Experience ist deutlich besser und die Zustellbarkeit war solide.Resendin 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.
---
Sicherheitsaspekte speziell für Auktionen
Auktionsplattformen ziehen Versuche der Gebotsmanipulation an. Shill Bidding (ein Seller treibt den Preis seines eigenen Lots mit gefälschten Konten in die Höhe), Account Takeovers um betrügerische Gewinngebote zu platzieren, und Zahlungsbetrug sind alle real und überproportional häufig im Vergleich zum typischen E-Commerce.
Ein paar Dinge würde ich von Anfang an einbauen:
- Rate Limiting bei der Gebotsabgabe — maximal N Gebote pro Benutzer pro Minute pro Los, erzwungen auf API-Ebene. Upstash Redis eignet sich gut dafür; es hat eine speziell dafür entwickelte Rate-Limiting-Bibliothek.— 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.
- E-Mail-Verifizierung vor Gebotsabgabe erlaubt — klingt offensichtlich, stoppt aber überraschend viel Missbrauch— sounds obvious, stops a surprising amount of abuse
- Fraud Scoring über Stripe Radar — bereits in Stripe enthalten, nutze es einfach— already included in Stripe, just use it
- IP- und Device-Fingerprinting für verdächtige Kontocluster — FingerprintJS Pro lohnt sich, wenn du in einer bedeutsamen Größenordnung operierst—FingerprintJS Prois worth the cost if you're operating at any meaningful scale
Ehrlich gesagt ist das Wichtigste das Logging. Protokolliere jeden Gebotsversuch, jeden fehlgeschlagenen Payment, jede Kontomassnahme. Wenn etwas schiefgeht — und das wird es — möchtest du eine vollständige Audit-Spur. Supabase's integriertes Logging plus ein leichtes Setup auf Axiom deckt das ab, ohne viel Aufwand.Axiomcovers this without much effort.
---
FAQ
Was ist der minimale MVP-Stack für eine kleine, lokale Auktionsseite?
Wenn du für ein lokales Auktionshaus mit vielleicht 200 Benutzern und wöchentlichen Verkäufen baust, brauchst du nicht Ably oder Typesense. WordPress mit einem Plugin wie Auctions for WooCommerce bringt dich überraschend weit. Ich habe drei dieser Seiten für regionale Auktionshäuser aufgebaut — Antiquitäten, Landmaschinen, solche Sachen. In dem Moment, wo du echtzeitgesteuertes kompetitives Bieten unter Last brauchst, wächst du schnell raus.Auctions 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.
Kann ich Firebase statt Supabase verwenden?
Das kannst du. Firestores Echtzeit-Zustandsverwaltung für Gebote ist tatsächlich ein vertretbarer Ansatz. Der Grund, warum ich 2026 Supabase bevorzuge, ist SQL — Auktionsdaten haben viel relationale Struktur (Lose gehören zu Verkäufen, Gebote gehören zu Losen und Benutzern, Rechnungen referenzieren Gebote), und Abfragen in einer Dokumentdatenbank dafür werden unübersichtlich. Aber wenn dein Team Firebase bereits sehr gut kennt, wechsle nicht um des Wechsels willen.
Wie handhabe ich Zeitzonen für Auktionsendzeiten?
Speichere alles in UTC. Immer. Zeige es in der lokalen Zeitzone des Benutzers über den Browser an. Das klingt offensichtlich und ich sehe es dennoch auf etwa einem von fünf Projekten falsch gemacht. Die Intl.DateTimeFormat API in modernen Browsern kümmert sich um die Anzeige ohne externe Bibliothek.Intl.DateTimeFormatAPI in modern browsers handles the display side without any library.
Brauche ich eine mobile App?
Nicht für ein MVP. Eine gut gebaute Progressive Web App mit Push-Benachrichtigungen (über die Web Push API) deckt 90% ab, was Bieter auf mobilen Geräten tatsächlich brauchen. Native Apps kommen später, wenn das Geschäft es rechtfertigt. Ich würde Expo und React Native verwenden, wenn dieser Tag kommt — gemeinsame Codebasis für iOS und Android, und das Team kennt React bereits.ExpoandReact Nativewhen that day arrives — shared codebase across iOS and Android, and the team already knows React.
---
Online-Auktionen zu betreiben ist eine legitime technische Herausforderung, die sich in einer täuschend einfachen Benutzeroberfläche verbirgt. Die Gebotsschnittstelle besteht aus drei Buttons und einer Zahl. Alles darunter — Konsistenz, Fairness, Echtzeitzustand, Betrugsprävention — ist der Ort, wo die echte Arbeit liegt. Schaff die richtige Infrastruktur von Anfang an und der Rest ist nur noch Features. Mach es falsch und du bist die Person, die einem Verkäufer erklärt, warum sein Los für £12 verkauft wurde.
Baue langweilige Infrastruktur. Baue interessante Produkte darauf.