Casestudy: eclipseando.com, een website en e-commerce-backend vanaf nul gebouwd in 19 dagen

Op 12 augustus 2026 was er een totale zonsverduistering boven Spanje. Op 24 juli bestond eclipseando.com niet: geen domein, geen ontwerp, geen regel code. Negentien dagen later stond de website online, met een pagina voor elke gemeente in Spanje, een webshop die via Stripe betaalde en een logistieke keten die bestellingen plaatste bij vier verschillende leveranciers. We vertellen het hier omdat dit het project is dat het best laat zien hoe we werken wanneer de opdracht "een website en een backend vanaf nul" is, en omdat elk onderdeel in productie staat en te bezoeken is.

De opdracht: een website met een houdbaarheidsdatum

Het project was van ons, niet van een klant, en dat maakt het een eerlijker voorbeeld: er was geen budget om op te rekken en geen onderhandelbare deadline. De datum werd bepaald door de hemel. De eisen kwamen voort uit voorafgaand onderzoek en waren concreet: de vraag "hoe laat en hoeveel zie ik vanuit mijn dorp?" beantwoorden voor elke gemeente in Spanje, gecertificeerde brillen en gepersonaliseerde souvenirs per gemeente verkopen, en dat ook doen in het Catalaans, Engels, Duits, Frans, Italiaans en Portugees, omdat een deel van het publiek uit het buitenland kwam.

We hebben Shopify en WooCommerce uitgesloten voordat we begonnen. Niet vanwege de prijs, maar omdat het moeilijke deel van het project niet de webshop was: het waren de 8.132 berekende pagina's, de kaart, de wolkenvoorspelling en logistieke koppelingen die geen enkel platform standaard meebrengt. Wanneer de waarde zit in wat niet standaard meekomt, staat het platform meer in de weg dan dat het helpt. Datzelfde criterium passen we toe wanneer een klant ons vraagt of hij zijn website op Odoo Website of apart moet bouwen.

Wat er is gebouwd, stuk voor stuk

De frontend: 8.132 pagina's die worden berekend, niet geschreven

Elke gemeente in Spanje heeft een eigen pagina met het begintijdstip, het maximum, het einde, het bedekkingspercentage en, in de totaliteitszone, de seconden duisternis. Die gegevens heeft niemand ingetypt: ze worden berekend op het moment dat de site wordt gegenereerd, op basis van de elementen van de zonsverduistering en de coördinaten van elke gemeente, en een test vergelijkt een steekproef van resultaten met die van het Instituto Geográfico Nacional. Als de berekening afwijkt, wordt de site niet gepubliceerd. Naast Spanje zijn er overzichten voor Portugal, Frankrijk, Italië, Duitsland, Ierland, IJsland, Groenland, Marokko, Nederland en het Verenigd Koninkrijk.

De meertaligheid is echt, geen automatische vertaling eroverheen: elke taal heeft een eigen pad (/ca/, /en/, /de/…), eigen teksten en eigen shoppagina's, en tests controleren dat de zeven versies van elk sjabloon bestaan en naar elkaar verwijzen. Het is dezelfde regel die we toepassen op flexigotech.com en pernocta.eu.

De backend: een kleine API die kassa, magazijn en balie in één is

Alles wat statisch is, wordt door nginx geserveerd. Alles wat dynamisch is, hangt onder /api/* en is een FastAPI-applicatie met de status in SQLite. Het klinkt bescheiden, en dat is bewust zo: één persoon onderhoudt het, het draait op een server van een paar euro en het verwerkte de piek op de dag van de zonsverduistering zonder aanpassingen. De beslissingen die ertoe doen zitten er binnenin:

• Het winkelmandje wordt op de server gewaardeerd. De browser bewaart de regels, maar elke prijs wordt herberekend aan de hand van de actuele catalogus bij het aanmaken van de betaalsessie. Anders opent iedereen de console en koopt een sweatshirt voor een euro.
• De Stripe-webhook beslist. Een betaling geldt als ontvangen wanneer Stripe die bevestigt met een geverifieerde handtekening, niet wanneer de browser terugkeert op de bedankpagina. Als de bestelling bij de leverancier mislukt na de betaling, geeft de API een foutmelding zodat Stripe het opnieuw probeert, en een tabel met de sessie-id voorkomt dat er twee keer wordt geproduceerd.
• Het digitale product wordt geleverd met een ondertekende link (HMAC, vervalt na 72 uur, maximaal vijf downloads) en het vakje voor afstand van het herroepingsrecht is verplicht vóór de betaling: de API weigert de checkout van de kit als het niet is aangevinkt.
• E-mails gaan niet verloren. Elke bevestiging verstuurt via Brevo; als Brevo niet reageert, komt de e-mail in een wachtrij in SQLite die een timer elke vijftien minuten leegt. Een koper zonder bevestigingsmail is een klacht, dus die regel kent geen uitzonderingen.

De logistieke koppelingen: vier leveranciers, vier manieren van communiceren

Dit is het deel dat het meest lijkt op wat klanten ons vragen. De webshop verkocht dingen die uit verschillende plaatsen kwamen, en elke plaats communiceerde op zijn eigen manier:

• Een drukkerij met API en webhook. Bij betaling genereert de API het printbestand (een SVG-sjabloon met de naam van de gemeente, het tijdstip en de duur, gerasterd op 300 dpi), maakt de bestelling aan en wacht op de webhook "verzonden" om de koper zijn tracking te sturen.
• Een tweede drukkerij met een fabriek in Barcelona voor kleding, omdat de eerste geen kleding in Spanje produceerde en de levertijd niet haalbaar was. Beide API's zijn met echte bestellingen gemeten voordat er werd beslist; de mok bleef bij de eerste omdat die wel hier werd gemaakt.
• Een brillenfabrikant met een dropshipping-API die verzendt naar Spanje, Frankrijk, Duitsland, het Verenigd Koninkrijk en Portugal. De bestelling wordt automatisch aangemaakt bij betaling, en vóór de betaling wordt de werkelijke beschikbaarheid per land opgevraagd.
• Een distributeur zonder API. Hij verzendt de brillen binnen 24-48 uur op het schiereiland en de Balearen, maar de bestelling wordt per e-mail doorgegeven. Het paneel levert met één klik precies wat hij nodig heeft: ontvanger, adres, telefoon, artikel en aantal, als tekst en als bijgevoegde CSV. En omdat zijn zendingen met GLS vertrekken, leest de API elke tien minuten de mailbox uit, classificeert de e-mails van de vervoerder (onderweg, in afhaalpunt met uiterste afhaaldatum, afwezig) en informeert de koper over elk daarvan.

Een gevolg dat klein lijkt en dat niet is: een bestelling met brillen en een T-shirt zijn twee pakketten van twee leveranciers. Daarom leeft de tracking per zending en niet per bestelling, met een rij voor elk paar bestelling-leverancier. Eén veld "trackingnummer" had gewerkt tot de eerste klant die beide kocht.

Levertijden worden gemeten, niet beloofd

De offerte-API van de drukkerij antwoordde "standaardlevering, 5-10 dagen" voor alles, ook voor producten die ze later weigerde bij een echte bestelling. Dat ontdekten we door een verkoop die niet geleverd kon worden. Sindsdien maakt een timer elke nacht een conceptbestelling aan voor elke combinatie van product en land, leest de vervoerder en de werkelijke dagen die de drukkerij teruggeeft, en verwijdert die. Die cijfers, en niet die uit de documentatie, ziet de koper op de productpagina voordat hij betaalt. Het is dezelfde les die we toepassen op Odoo-connectoren: een groene test tegen een mock bewijst niets; je moet meten tegen het echte systeem.

Wat vanzelf draait

Zeven systemd-units doen wat in een kleine webshop meestal iemand met de hand doet: elke tien minuten de mailbox van de vervoerder uitlezen, de e-mailwachtrijen leegmaken en betaalde bestellingen zonder productie elke vijftien minuten opnieuw proberen, elke drie uur de wolkenvoorspelling van AEMET verversen voor de meest bezochte gemeenten en dagelijks de levertijden van de drukkerij meten. Geen enkele roept een externe dienst aan in het pad van een webverzoek: de pagina's lezen uit de cache, en een test garandeert dat.

Wat hiervan bruikbaar is voor jouw webshop

Bijna alles, als je de zonsverduistering vervangt door jouw assortiment. Wat een klant ons vraagt wanneer hij zegt "ik wil een e-commerce-website vanaf nul" is precies deze lijst: een snelle, meertalige frontend, een kassa die niet te foppen is, koppelingen met wie produceert en wie verzendt, tracking die de klant bereikt zonder dat iemand die met de hand overtypt, en taken die vanzelf draaien. Wanneer de klant al Odoo heeft, wordt die API vervangen door het ERP zelf en zijn de koppelingen vervoerderconnectoren binnen Odoo; wanneer hij dat niet heeft, of zijn bedrijf niet in een ERP past, wordt het gebouwd zoals hier.

Veelgestelde vragen

Nuttige links binnen FlexigoTech

Wat wij hierover doen