Zum Inhalt springen
← Alle Projekte

Gado Imkerei

Website und Webshop für eine Imkerei in Däniken SO: vom Warenkorb bis zur bezahlten Bestellung.

Rolle
Alleinentwickler, Auftrag einer externen Kundin
Zeitraum
Juli bis September 2026
  • React 19
  • TypeScript
  • Tailwind CSS v4
  • Supabase
  • Postgres
  • Row Level Security
  • Deno
  • Stripe
  • Resend
  • ASPSMS
  • Vercel

Worum es ging

Eine Imkerei verkaufte bis dahin ab Hof und über Zurufe. Gesucht war ein Auftritt, über den auch bestellt werden kann, ohne dass daraus ein Betrieb wird, den jemand täglich bedienen muss.

Entstanden ist der vollständige Kaufweg: Warenkorb, Kasse mit Abholung oder Versand, Bestellung per Formular oder WhatsApp, Stripe Checkout mit Karte und TWINT, Kundenkonto, Bestellmeldung per E-Mail und SMS und eine geschützte Auswertung für die Kundin. Dazu die Schweizer Rechtstexte, die ein Verkauf an Konsumenten verlangt.

Mitten im Projekt änderte sich der Umfang: Versand und Online-Zahlung kamen dazu, nachdem die Kasse für Abholung bereits stand. Aus der One-Page-Site wurde ein Shop mit Datenbank, Zahlungsanbieter und Meldewegen. Das ist der Teil, der sich in einem Eigenprojekt nicht simulieren lässt: Der Entwurf muss eine Änderung aushalten, die man sich nicht ausgesucht hat.

Zahlen

Zeilen Code
~8000 Zeilen Code
Zahlarten: Karte, TWINT, bar
3 Zahlarten: Karte, TWINT, bar
externe Auftraggeberin
1 externe Auftraggeberin

Einblicke

Hero: Ort, Nutzen, Kaufweg und Vertrauen in drei Sekunden, ein starkes Foto statt Slideshow.
Sorten mit Jahrgang, Verfügbarkeit und Preis, ein eigenes Foto pro Ernte.
Kasse: Abholung oder Versand, Zahlung online oder vor Ort, Bestellung mit oder ohne Konto.
Mobil: Text und Schaltfläche ohne Scrollen sichtbar und tippbar.

Eine Lücke in der eigenen Insert-Policy, selbst gefunden

Bei einem Sicherheitsdurchgang gegen die eigene Datenbank liess sich über den öffentlichen anon-Key eine Bestellung mit dem Status "bezahlt" und beliebigem Betrag anlegen, und die Datenbank antwortete mit 201. Row Level Security war aktiv, aber die Insert-Policy prüfte nur, wer schreiben darf, nicht was geschrieben wird. Die Policy verlangt seither einen definierten Anfangszustand; "bezahlt" kann ausschliesslich der signierte Stripe-Webhook setzen. Die eigentliche Lehre steckt nicht im Fix, sondern in der Frage, die ihn gefunden hat: Nicht "ist RLS an?", sondern "was kann jemand mit dem Schlüssel tun, der ohnehin im Browser liegt?".

Stack

Frontend
  • React 19
  • TypeScript (strict)
  • Vite 8
  • Tailwind CSS v4
  • shadcn auf Base UI
  • lucide-react
  • Fontsource
Backend
  • Supabase
  • Postgres mit Row Level Security
  • Auth mit eigenen Mail-Vorlagen
  • vier Edge Functions in Deno
  • SQL-Migrationen über die Supabase CLI
  • Region Zürich
Zahlung und Kommunikation
  • Stripe Checkout mit Karte und TWINT
  • signierte Webhooks
  • Erstattung
  • Resend auf eigener Domain
  • ASPSMS
  • WhatsApp-Deeplinks
Qualität und Betrieb
  • ESLint
  • tsc als Build-Gate
  • eigene Prüfskripte vor jedem Build
  • Vercel mit SPA-Rewrites
  • WebP-Bildpipeline

Status

Abgeschlossen, seit September 2026 live unter gadoimkerei.ch. Repository privat, Einsicht auf Anfrage.