Referenzprojekt: eclipseando.com, eine Website und ein E-Commerce-Backend, in 19 Tagen von Grund auf gebaut

Am 12. August 2026 gab es über Spanien eine totale Sonnenfinsternis. Am 24. Juli existierte eclipseando.com noch nicht: keine Domain, kein Design, keine einzige Zeile Code. Neunzehn Tage später war die Website online, mit einer Seite für jede Gemeinde Spaniens, einem Shop, der per Stripe kassierte, und einer Logistikkette, die Bestellungen bei vier verschiedenen Lieferanten auslöste. Wir erzählen das hier, weil es das Projekt ist, das am besten zeigt, wie wir arbeiten, wenn der Auftrag «eine Website und ein Backend von Grund auf» lautet, und weil jedes Teil in Produktion ist und besucht werden kann.

Der Auftrag: eine Website mit Verfallsdatum

Das Projekt gehörte uns, nicht einem Kunden, und gerade deshalb ist es ein ehrlicheres Beispiel: Es gab kein Budget, das man strecken konnte, und keinen verhandelbaren Termin. Das Datum bestimmte der Himmel. Die Anforderungen ergaben sich aus einer vorherigen Recherche und waren konkret: für jede Gemeinde Spaniens die Frage «Um wie viel Uhr und wie viel sehe ich von meinem Ort aus?» beantworten, geprüfte Brillen und nach Gemeinde personalisierte Andenken verkaufen und das Ganze auch auf Katalanisch, Englisch, Deutsch, Französisch, Italienisch und Portugiesisch anbieten, weil ein Teil des Publikums aus dem Ausland kam.

Shopify und WooCommerce haben wir vor dem Start ausgeschlossen. Nicht wegen des Preises, sondern weil das Schwierige an dem Projekt nicht der Shop war: Es waren die 8.132 berechneten Seiten, die Karte, die Wolkenprognose und logistische Integrationen, die keine Plattform serienmäßig mitbringt. Wenn der Wert in dem liegt, was nicht serienmäßig dabei ist, steht die Plattform mehr im Weg, als sie hilft. Dasselbe Kriterium wenden wir an, wenn uns ein Kunde fragt, ob er seine Website auf Odoo Website oder getrennt davon aufbauen soll.

Was gebaut wurde, Baustein für Baustein

Das Frontend: 8.132 Seiten, die berechnet statt geschrieben werden

Jede Gemeinde Spaniens hat ihre eigene Seite mit Beginnzeit, Maximum, Ende, Verdeckungsgrad und, im Totalitätsstreifen, den Sekunden der Dunkelheit. Diese Daten hat niemand geschrieben: Sie werden beim Generieren der Website aus den Elementen der Finsternis und den Koordinaten jeder Gemeinde berechnet, und ein Test gleicht eine Stichprobe der Ergebnisse mit denen ab, die das spanische Geografische Institut (Instituto Geográfico Nacional) veröffentlicht. Weicht die Berechnung ab, wird die Website nicht veröffentlicht. Neben Spanien gibt es Verzeichnisse für Portugal, Frankreich, Italien, Deutschland, Irland, Island, Grönland, Marokko, die Niederlande und das Vereinigte Königreich.

Die Mehrsprachigkeit ist echt und keine darübergelegte automatische Übersetzung: Jede Sprache hat ihren eigenen Pfad (/ca/, /en/, /de/…), ihre eigenen Texte und ihre eigenen Shopseiten, und Tests prüfen, dass die sieben Versionen jeder Vorlage existieren und aufeinander verweisen. Es ist dieselbe Regel, die wir auf flexigotech.com und pernocta.eu anwenden.

Das Backend: eine kleine API als Kasse, Lager und Verkaufstresen

Alles Statische liefert nginx aus. Das Dynamische hängt an /api/* und ist eine FastAPI-Anwendung mit dem Zustand in SQLite. Das klingt bescheiden, und das ist Absicht: Eine Person pflegt es, es läuft auf einem Server für wenige Euro und hat den Ansturm am Tag der Finsternis ohne jede Änderung verkraftet. Die wichtigen Entscheidungen stecken im Inneren:

• Der Warenkorb wird auf dem Server bewertet. Der Browser speichert die Positionen, aber jeder Preis wird beim Erstellen der Zahlungssitzung gegen den aktuellen Katalog neu berechnet. Sonst öffnet jemand die Konsole und kauft ein Sweatshirt für einen Euro.
• Der Stripe-Webhook entscheidet. Eine Zahlung gilt als eingegangen, wenn Stripe sie mit verifizierter Signatur bestätigt, nicht wenn der Browser zur Dankesseite zurückkehrt. Schlägt beim Kassieren die Bestellung beim Lieferanten fehl, antwortet die API mit einem Fehler, damit Stripe es erneut versucht, und eine Tabelle mit der Sitzungskennung verhindert, dass doppelt produziert wird.
• Das digitale Produkt wird über einen signierten Link ausgeliefert (HMAC, läuft nach 72 Stunden ab, höchstens fünf Downloads), und das Kontrollkästchen zum Verzicht auf das Widerrufsrecht ist vor dem Bezahlen Pflicht: Die API lehnt den Checkout des Kits ab, wenn es nicht angehakt ist.
• E-Mails gehen nicht verloren. Jede Bestätigung läuft über Brevo; antwortet Brevo nicht, landet sie in einer Warteschlange in SQLite, die ein Timer alle fünfzehn Minuten leert. Ein Käufer ohne Bestätigungs-E-Mail ist eine Reklamation, deshalb gibt es bei dieser Regel keine Ausnahmen.

Die Logistikschnittstellen: vier Lieferanten, vier Arten der Kommunikation

Hier liegt der Teil, der dem am meisten ähnelt, was Kunden bei uns anfragen. Der Shop verkaufte Dinge, die von unterschiedlichen Orten ausgeliefert wurden, und jeder Ort kommunizierte auf seine Weise:

• Eine Druckerei mit API und Webhook. Beim Kassieren erzeugt die API die Druckdatei (eine SVG-Vorlage mit Gemeindename, Uhrzeit und Dauer, mit 300 ppp gerastert), legt die Bestellung an und wartet auf den Webhook «versendet», um dem Käufer seine Sendungsverfolgung zu schicken.
• Eine zweite Druckerei mit Produktionsstätte in Barcelona für die Kleidung, weil die erste keine Textilien in Spanien fertigte und die Lieferzeit nicht reichte. Vor der Entscheidung wurden beide APIs mit echten Bestellungen gemessen; die Tasse blieb bei der ersten, weil diese sie hier fertigte.
• Ein Brillenhersteller mit Dropshipping-API, der nach Spanien, Frankreich, Deutschland, ins Vereinigte Königreich und nach Portugal liefert. Die Bestellung wird beim Kassieren automatisch angelegt, und vor dem Kassieren wird die tatsächliche Verfügbarkeit pro Land abgefragt.
• Ein Distributor ohne API. Er versendet die Brillen innerhalb von 24 bis 48 Stunden auf dem Festland und den Balearen, aber die Bestellung wird ihm per E-Mail übermittelt. Das Panel erzeugt mit einem Klick genau das, was er braucht: Empfänger, Adresse, Telefon, Artikel und Menge, als Text und als angehängte CSV-Datei. Und da seine Sendungen mit GLS rausgehen, liest die API alle zehn Minuten das Postfach, klassifiziert die E-Mails des Zustellers (unterwegs, in der Abholstation mit Abholfrist, Empfänger nicht angetroffen) und benachrichtigt den Käufer bei jeder einzelnen.

Eine Folge, die klein wirkt und es nicht ist: Eine Bestellung mit Brillen und einem T-Shirt sind zwei Pakete von zwei Lieferanten. Deshalb liegt die Sendungsverfolgung pro Sendung und nicht pro Bestellung, mit einer Zeile für jedes Paar aus Bestellung und Lieferant. Ein einzelnes Feld «Sendungsnummer» hätte funktioniert, bis zum ersten Kunden, der beides kauft.

Lieferzeiten werden gemessen, nicht versprochen

Die Angebots-API der Druckerei antwortete für alles «Standardlieferung, 5-10 Tage», auch für Produkte, die sie bei der echten Bestellung dann ablehnte. Wir haben es durch einen Verkauf entdeckt, der nicht geliefert werden konnte. Seitdem legt ein Timer jede Nacht für jede Kombination aus Produkt und Land eine Entwurfsbestellung an, liest den Zusteller und die tatsächlichen Tage aus, die die Druckerei zurückgibt, und löscht sie wieder. Diese Zahlen, nicht die der Dokumentation, sieht der Käufer auf der Produktseite, bevor er bezahlt. Es ist dieselbe Lehre, die wir auf Odoo-Konnektoren anwenden: Ein grüner Test gegen einen Mock beweist nichts; man muss am echten System messen.

Was von allein läuft

Sieben systemd-Units erledigen, was in einem kleinen Shop sonst jemand von Hand macht: alle zehn Minuten das Postfach des Zustellers lesen, alle fünfzehn die E-Mail-Warteschlangen leeren und bezahlte, aber nicht produzierte Bestellungen erneut versuchen, alle drei Stunden die Wolkenprognose der AEMET für die meistgesuchten Gemeinden aktualisieren und täglich die Lieferzeiten der Druckerei messen. Keine davon ruft im Verlauf einer Webanfrage einen externen Dienst auf: Die Seiten lesen aus dem Cache, und ein Test stellt das sicher.

Was davon für Ihren Shop taugt

Fast alles, wenn man die Finsternis durch Ihren Katalog ersetzt. Was ein Kunde von uns verlangt, wenn er sagt «Ich möchte eine E-Commerce-Website von Grund auf», ist genau diese Liste: ein schnelles, mehrsprachiges Frontend, eine Kasse, die sich nicht austricksen lässt, Integrationen mit denen, die produzieren, und denen, die versenden, eine Sendungsverfolgung, die den Kunden erreicht, ohne dass jemand sie von Hand kopiert, und Aufgaben, die von allein laufen. Hat der Kunde bereits Odoo, ersetzt das ERP selbst diese API, und die Integrationen sind Zusteller-Konnektoren innerhalb von Odoo; hat er es nicht oder passt sein Geschäft nicht in ein ERP, wird es gebaut wie hier.

Häufige Fragen

Nützliche Links bei FlexigoTech

Was wir dazu anbieten