2021 kam ein Kunde zu mir mit einer Anfrage, die sich einfach anhörte: „Wir brauchen eine Auktionsseite. Wie eBay, aber eine Nische – Oldtimer-Motorradteile." Drei Monate, zwei verworfene Prototypen und ein echtes Produktions-Desaster später hatte ich eine Meinung. Eine starke. Am Ende haben wir es geschafft, aber ich würde es heute nicht mehr so bauen. Überhaupt nicht.
Wichtigste Erkenntnisse: Eine Auktionsplattform für 2026 ist Next.js, Supabase mit Echtzeit-Kanälen für Live-Bieten und Stripe; die schwierige Partie ist die Konsistenz des Bid-Status unter Concurrency, nicht der Stack.A 2026 auction platform is Next.js, Supabase with realtime channels for live bidding, and Stripe; the hard part is bid-state integrity under concurrency, not the stack.
Auktionsplattformen sind heimtückisch schwierig. Oberflächlich betrachtet geht es nur um Angebote, Gebote und einen Timer. Aber sobald zwei Nutzer innerhalb von Millisekunden bieten, oder deine WebSocket-Verbindung fällt genau aus, wenn der Countdown bei Null ankommt, oder dein Zahlungsabwickler bricht während der Erfassung ab -- plötzlich erklärst du einem sehr wütenden Verkäufer, warum seine 1967 BSA Lightning für £12 verkauft wurde. Also lass mich dich durchführen, was ich 2026 tatsächlich bauen würde, Tool für Tool, Entscheidung für Entscheidung.
---
Die Architektur-Grundentscheidung: Monolith oder Services?
Lass dich nicht von jemandem Microservices für eine erste Version verkaufen. Ich meine das 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 wird nichts ausgeliefert, weil das Team an Inter-Service-Latenz auf einer Plattform mit 40 Nutzern debuggt. Für ein Auktions-MVP oder sogar ein moderat skaliertes Produkt (sagen wir, unter 50.000 monatlich aktiven Nutzern), ist ein modularer Monolith die richtige Wahl.modular monolith is the right call.
Worauf ich greifen würde: Next.js für das Frontend und die API-Schicht, 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 tatsächlich zählt, wirklich reduziert -- du möchtest, dass diese Los-Beschreibungen indexiert werden. Die API-Routes handhaben leichtere Aufgaben; das schwere Echtzeit-Material lebt woanders (mehr dazu gleich).Next.js on 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 -- Nutzer, Lose, Gebote, Mindestpreise, Rechnungen -- und du möchtest, dass Foreign-Key-Constraints echte Arbeit leisten, nicht gefühlsbasierte Anwendungslogik. Ich würde es 2026 auf Supabase laufen lassen, weil du Postgres, Row-Level-Security und eine echte Echtzeit-Abo-Schicht erhältst, alles baked in, was das zusammenbricht, was früher drei separate Infrastruktur-Anliegen waren, in eine Rechnung.Supabase in 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 brechen wird
Hier sterben die meisten Auktionsplattformen. Oder hinken zumindest.
Das grundlegende Problem: Gebotsabgabe muss sich augenblicklich anfühlen, muss konsistent sein und muss Race Conditions korrekt handhaben. Wenn zwei Nutzer in derselben Millisekunde ein Gebot abgeben, gewinnt einer von ihnen. Die Datenbank entscheidet, wer. Nicht das Frontend, nicht der Load Balancer -- die Datenbank, über eine ordnungsgemäß geschriebene Transaktion mit SELECT FOR UPDATE.SELECT FOR UPDATE.
Für die Real-Time-Schicht selbst würde ich 2026 Ably verwenden, statt rohe WebSockets selbst zu schreiben. Ich habe den Raw-Ansatz 2022 bei einem Immobilienauktionsprojekt bei Seahawk versucht -- self-hosted socket.io, Redis pub/sub, alles zusammen. Es funktionierte, bis es nicht mehr funktionierte. Ably garantiert dir die Nachrichtenreihenfolge, Connection-State-Recovery (falls das Telefon eines Bieters während der Auktion von WiFi zu 4G wechselt, verpassen sie nicht stumm das Gewinnergebot) und ein vernünftiges Dashboard. Die Preisgestaltung im großen Maßstab ist real, aber für die meisten Auktionsveranstalter ist das Peanuts gegenüber der Infrastrukturkomplexität.Ably in 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.
Umgang mit dem Problem des "Bid Sniping"
Auction Sniping -- ein Gebot in den letzten Sekunden platzieren -- ist entweder ein Feature oder ein Bug, je nachdem, was dein Kunde will. eBay erlaubt es bekanntermaßen. Viele spezialisierte Auktionshäuser verlängern den Timer um 30-60 Sekunden, wenn ein Gebot in der letzten Minute ankommt. Das nennt sich "Soft Close" oder "Anti-Sniping"-Logik. Baue es von Anfang an ein. Die Regel ist einfach:
- Gebot kommt mit weniger als N Sekunden verbleibend an
- Transaktion bestätigt, dass das Gebot gültig und das höchste ist
- Auktionsendzeit verlängert sich um N Sekunden
- Neue Endzeit wird an alle verbundenen Clients über Ably übertragen
Das sind vielleicht 40 Zeilen Server-Logik. Es zu überspringen und später reinzuquetschen ist ein Kopfzerbrechen, das du nicht willst.
---
Zahlungen: Halte es einfach
Ich habe gesehen, dass Leute auf Auktionsplattformen zu exotischen Zahlungslösungen greifen, weil Auktionen besondere Anforderungen haben – du erfasst Zahlungsdetails im Voraus, belastest das Konto erst, wenn die Auktion endet, musst möglicherweise eine Kaution halten, musst möglicherweise sofort rückzahlen, wenn jemand überbietet. Alles korrekt. Alles lässt sich mit Stripe lösen, ohne die Stripe-Dokumentation zu verlassen.
Stripe ist 2026 immer noch die richtige Antwort für die überwiegende Mehrheit der Auktionsbetreiber. Konkret: in 2026 is still the right answer for the vast majority of auction operators. Specifically:
- Stripe Payment Intents für den Standard-Gebot-zu-Belastung-Ablauf for the standard bid-to-charge flow
capture_method: manual, um eine Karte zu autorisieren, ohne sie zu belasten (essentiell für Kautionshaltung)to authorise a card without charging it (essential for deposit holds)- Stripe Connect, falls du einen Marktplatz aufbaust, auf dem mehrere Verkäufer Auszahlungen erhalten
Das eine, das ich hervorheben würde: Autorisiere Karten nicht für den vollen Lotwert im Voraus, es sei denn, eine rechtliche Beratung sagt dir, dass du das musst. Autorisiere für eine Kaution (10–25 % ist in der Auktionswelt üblich), erfasse oder storniere dann, sobald die Auktion endet. Deine Kartenabrechnungsquoten werden es dir danken.
Für höherwertige Auktionshäuser – Oldtimer, Fine Art und dergleichen – solltest du Banküberweisung akzeptieren. Stripe handhabt das mittlerweile angemessen über ihre Payment-Link- und Invoice-Produkte, aber du brauchst immer noch eine Person vor Ort für die Abstimmung. Baue eine einfache Admin-Warteschlange dafür; automatisiere nicht, was nicht automatisiert werden muss.
---
Suche und Filterung: Typesense, nicht Elasticsearch
Ehrlich gesagt wird die Suchfunktion auf Auktionsplattformen unterschätzt. Nutzer müssen nach Kategorie, aktuellem Preis, verbleibender Zeit, Zustand und Standort filtern können. Und sie brauchen es schnell.
Elasticsearch ist für die meisten Auktionsseiten Overkill und ein echtes Kopfzerbrechen im Betrieb. Ich würde Typesense verwenden. Es ist Open Source, du kannst es selbst auf einem 6-Dollar-DigitalOcean-Droplet hosten oder Typesense Cloud nutzen, und die Suchqualität ist für katalogähnliche Daten hervorragend. Synchronisiere deine PostgreSQL-Lots-Tabelle mit Typesense über einen einfachen Change-Data-Capture-Hook oder einen Cron-Job alle 30 Sekunden (echtzeitliche Synchronisation von Auktionslos-Preisen ist schön, aber für die Suche selten notwendig).Typesense is 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, bei dem Typesense out of the box nicht gut funktioniert: Geosuche für Artikel, die nur lokal abgeholt werden können. Es hat zwar Geo-Filterung, aber wenn deine Auktionsseite viel „nur Selbstabholung"-Inventar hat, investiere früh einen halben Tag in diese Konfiguration. Ich habe das nicht getan – bei einer Gartenmaschinenbörse 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 -- Deployments ohne Konfiguration, Preview-URLs pro Branch, Edge Functions wo nötig for the Next.js frontend and API routes -- zero config deployments, preview URLs per branch, edge functions where needed
- Supabase für PostgreSQL und Auth for PostgreSQL and auth
- Ably für WebSockets for WebSockets
- Typesense Cloud für die Suche for search
- Cloudflare vor allem -- kostenlos: DDoS-Schutz, Bildoptimierung und Caching ohne Umschweife in front of everything -- free tier handles DDoS, image optimisation, and caching without fuss
- Uploadcare oder Cloudinary für von Verkäufern hochgeladene Objektbilder (speichert Nutzer-Uploads 2026 bitte nicht mehr auf eurem eigenen Server) or Cloudinary for seller-uploaded lot images (never store user uploads on your own server in 2026, please)
Dieser Stack braucht kein Kubernetes, keinen selbst verwalteten Redis-Cluster, keine DevOps-Einstellung. Ein einzelner Developer oder kleines Team kann ihn betreiben. Und entscheidend -- er skaliert ohne Neuarchitektur. Vercel und Supabase handhaben den Traffic-Anstieg, wenn ihr in einer Fachpublikation erwähnt werdet und 8.000 Menschen deine Seite in einer Stunde besuchen.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.
Ein Infrastruktur-Fehler, den ich ständig sehe
Menschen vergessen Background-Jobs. Auktionsende-Events werden nicht vom Nutzer ausgelöst -- sie passieren zu einem bestimmten Zeitstempel, serverseitig. Du brauchst einen zuverlässigen Job-Scheduler. Ich würde 2026 Inngest nutzen. Es handhabt zeitgesteuerte Trigger, Wiederholungen und gibt dir ein Event-Log, das wirklich nützlich ist, wenn du debuggst, warum Los 447 ohne Winner-Email-Versand geschlossen wurde. Nutze keinen einfachen Cron auf deinem Server. Wenn dein Server neu startet, ist dein Cron-Status weg.Inngest for 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 simple cron on your server. When your server restarts, your cron state is gone.
---
Admin- und Verkäufer-Tools
Verkäufer müssen Listings erstellen, Bilder hochladen, Mindestgebote setzen und Gebotshistorien ansehen. Käufer brauchen Merklisten, Gebotsalarme und Rechnungs-Downloads. Das sind keine glamourösen Features. Das sind die Features, bei denen dich Clients um 21 Uhr Donnerstagabend anrufen.
Für das Admin-Panel würde ich leicht auf Retool oder ein custom Next.js-Dashboard aufbauen, je nach Budget. Retool ist wirklich schnell zu implementieren und handhabt 80% der Auktions-Admin-Aufgaben -- Listings genehmigen, Nutzer verwalten, Gebote ungültig machen -- ohne viel Code zu schreiben. Für alles, das Clients sehen, würde ich ordentlich in Next.js bauen, denn Retool in einem Iframe ist keine gute User Experience.Retool or 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-Benachrichtigungen -- Übergebote-Alerts, Los schließt bald, Rechnung bereit -- gehen 2026 durch Resend. Es hat SendGrid in meinem Stack vor etwa 18 Monaten ersetzt und ich habe nicht zurückgeblickt. Die Developer Experience ist deutlich besser und die Zustellbarkeit war solide.Resend in 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 spezifisch für Auktionen
Auktionsplattformen sind ein Ziel für Manipulationsversuche bei Geboten. Shill Bidding (ein Verkäufer treibt den Preis seines eigenen Loses mit gefälschten Konten in die Höhe), Kontoübernahmen zum Platzieren betrügerischer Gewinngebote und Zahlungsbetrug sind alle real und deutlich häufiger als bei typischem E-Commerce.
Ein paar Dinge, die ich von Anfang an einbauen würde:
- Rate Limiting bei der Gebotsabgabe -- maximal N Gebote pro Benutzer pro Minute pro Los, erzwungen auf der API-Ebene. Upstash Redis ist dafür gut; es hat eine speziell 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 dem Bieten -- klingt offensichtlich, stoppt aber überraschend viel Missbrauch -- sounds obvious, stops a surprising amount of abuse
- Fraud Scoring über Stripe Radar -- bereits in Stripe enthalten, nutzen Sie es einfach -- already included in Stripe, just use it
- IP- und Device-Fingerprinting für verdächtige Kontogruppen -- FingerprintJS Pro ist die Kosten wert, wenn Sie in einer bedeutsamen Größenordnung tätig sind -- FingerprintJS Pro is worth the cost if you're operating at any meaningful scale
Ehrlich gesagt ist das Wichtigste das Logging. Loggen Sie jeden Gebotsversuch, jeden fehlgeschlagenen Payment, jede Kontenaktion. Wenn etwas schiefgeht -- und es wird schiefgehen -- möchten Sie eine vollständige Audit-Spur. Supabase's eingebautes Logging plus ein leichtes Setup auf Axiom deckt das ab, ohne viel Aufwand.Axiom covers this without much effort.
---
FAQ
Welcher minimale Tech-Stack eignet sich für eine kleine, lokale Auktionsplattform?
Wenn du für ein lokales Auktionshaus mit vielleicht 200 Nutzern und wöchentlichen Verkäufen baust, brauchst du weder Ably noch Typesense. WordPress mit einem Plugin wie Auctions for WooCommerce bringt dich überraschend weit. Ich habe drei solcher Plattformen für regionale Auktionshäuser aufgesetzt -- Antiquitäten, Landmaschinen, solche Sachen. In dem Moment, in dem du echtzeitfähige Gebotsabgaben unter Last brauchst, wächst du schnell raus.WordPress with a plugin like Auctions for WooCommerce gets 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?
Ja, kannst du. Firestores von Firebase ist eigentlich ein vernünftiger Fit für den Echtzeit-Gebotsstatus. 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 Nutzern, Rechnungen referenzieren Gebote), und ein Dokument-Datenbankensystem dafür abzufragen wird chaotisch. Aber wenn dein Team Firebase bereits sehr gut kennt, wechsel nicht nur um des Wechsels willen.
Wie handhabe ich Zeitzonen für Auktionsendzeiten?
Speichere alles in UTC. Immer. Zeige die lokale Zeitzone des Nutzers über den Browser an. Das klingt offensichtlich und ich sehe es trotzdem auf etwa jedem fünften Projekt falsch gemacht. Die Intl.DateTimeFormat API in modernen Browsern kümmert sich um die Anzeige ohne externe Bibliothek.Intl.DateTimeFormat API in modern browsers handles the display side without any library.
Brauche ich eine mobile App?
Nicht für ein MVP. Eine gut gemachte Progressive Web App mit Push-Benachrichtigungen (via Web Push API) deckt 90% ab, was Bieter mobil wirklich brauchen. Native Apps kommen später, wenn das Geschäft es rechtfertigt. Ich würde Expo und React Native nutzen, wenn dieser Tag kommt -- gemeinsamer Code für iOS und Android, und das Team kennt React bereits.Expo and React Native when 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 hinter einer täuschend einfachen UI verbirgt. Die Bieterschnittstelle besteht aus drei Buttons und einer Zahl. Alles darunter -- Konsistenz, Fairness, Echtzeit-Zustand, Betrugsprävention -- das ist der Ort, wo die eigentliche Arbeit stattfindet. Wenn du den Stack von Anfang an richtig aufbaust, ist der Rest nur Features. Machst du es falsch, bist du derjenige, der einem Verkäufer erklären muss, warum sein Los für £12 verkauft wurde.
Baue langweilige Infrastruktur. Baue interessante Produkte darauf.