Manche Ideen begleiten einen über Jahre. Ginolino ist so eine. Zusammen mit meiner Partnerin hatte ich sie schon lange im Kopf. Ausgelöst von einem sehr konkreten Ärgernis: dem Überfluss an Geschenken. Gerade bei Kindergeburtstagen oder runden Geburtstagen kommt oft zu viel Kleines zusammen und das eine grosse, sinnvolle Geschenk scheitert an der Koordination. Wer gibt wie viel? Wer hat schon bezahlt? Und was ist überhaupt schon zusammengekommen?
Irgendwann wollten wir nicht mehr nur darüber reden, sondern es ausprobieren. Und weil wir bei Prine den Prototype Sprint als Format anbieten, lag es nahe, ihn einmal am eigenen Projekt zu erleben.
Die Idee stand – es fehlte die Umsetzung
Konzeptionell war Ginolino längst durchdacht. Der Kern: Statt Listen und Nachfragen sieht man das Geschenk als Bild. Jeder Teil ist ein sichtbares Feld mit einem Preis, die Gäste wählen genau den Teil, den sie beisteuern möchten, und überweisen ihren Anteil per Twint.
Was fehlte, war die Umsetzung. Und genau da wird es für uns als Software-Entwickler interessant, denn wie man von einer klaren Idee zu funktionierender Software kommt, ist selten eine Frage des «ob», sondern des «wie».
Kein Wegwerf-Prototyp
Der bequeme Weg wäre gewesen, das Ganze schnell in einem AI Prototyping-Tool wie Lovable zusammenzuklicken. Das Resultat wäre aber ein Wegwerf-Prototyp gewesen: hübsch für eine Demo, aber ohne tragfähiges Fundament, ohne unsere gewohnte Architektur und ohne die Security-Standards, mit denen wir sonst arbeiten. Dazu kommt: Das mitgelieferte Hosting und die Supabase-Basis, auf der solche Tools im Hintergrund aufsetzen, erachten wir für skalierbare Architekturen als nicht optimal.
Das wollten wir bewusst nicht. Stattdessen haben wir Ginolino von Beginn weg auf unserem produktiven Boilerplate aufgesetzt: unser klassischer Stack aus Laravel im Backend und Vue 3 im Frontend. Also exakt die Grundlage, auf der auch unsere Kundenprojekte laufen. Damit ist der Prototyp kein Sackgassen-Artefakt, sondern ein echtes technisches Fundament, auf dem man weiterbauen kann.
Der Workflow: spec-driven, eng begleitet
Der eigentliche Hebel liegt im Vorgehen. Wir haben die Features nicht «vibe-coded», sondern spec-driven und Schritt für Schritt umgesetzt:
- Design mit Claude (Fable 5): Fable 5 hilft enorm dabei, aus einer Feature-Beschreibung ein durchdachtes Design und eine saubere Spezifikation zu machen. Wir gehen Feature für Feature durch und schärfen jeweils genau, was gebaut werden soll.
- Umsetzung mit Unterstützung von Claude Code (Opus 4.8): Features werden in kleine, funktionale Schritte aufgeteilt. Wir schreiben nach wie vor selbst Code und setzen Claude Code gezielt dort ein, wo wir unsere Effizienz am stärksten steigern können. Jeder Merge Request wird zusätzlich von einem Team-Mitglied reviewt – so bleibt die Codequalität auf dem Niveau, das wir aus unseren Kundenprojekten kennen.
Was in diesem Prozess den entscheidenden Unterschied macht: Wir wissen als Software-Entwickler genau, welche Reihenfolge logisch und am einfachsten ist, um schnell und zielführend zu einem Resultat zu kommen. Datenmodell zuerst, dann die Kern-Flows, dann das Drumherum. Die KI beschleunigt jeden einzelnen Schritt enorm, aber die Abfolge und die Architekturentscheidungen kommen von uns. Genau diese enge Begleitung ist der Unterschied zwischen einem Prototyp, der zufällig funktioniert, und einem, der auch trägt.
Das Finetuning – die letzten kleinen Anpassungen an Layout, Wording und Details – machen wir bewusst von Hand.
Hosting und Deployment wie im Kundenprojekt
Auch beim Deployment sind wir nicht vom gewohnten Weg abgewichen: Über unsere bestehenden GitLab-Pipelines konnten wir Build, Test und Deployment genau gleich abwickeln wie in unseren anderen Projekten. Kein separates Setup, keine Insellösung – derselbe automatisierte Prozess, der sich bei uns bereits bewährt hat. Genau das ist der Vorteil eines Prototyps auf dem produktiven Stack: Er lässt sich vom ersten Tag an so betreiben und weiterentwickeln wie richtige Software.
Das Resultat: ein Tag, eine Webapp mehr als nur ein MVP
Am Ende des Tages stand keine Demo, sondern eine bedienbare Web-App: ein Geschenk lässt sich anlegen, Teile werden mit Preisen auf dem Foto platziert, Gäste erhalten einen Link, wählen ihren Teil und sehen den Fortschritt in Echtzeit. Alles auf unserem eigenen Stack, mit der Security und der Codequalität, die wir uns gewohnt sind.
Das ist für uns die eigentliche Stärke dieses Vorgehens: Man verbindet die Geschwindigkeit von KI-gestützter Entwicklung mit der Verlässlichkeit eines produktiven Fundaments. Kein Bruch zwischen «Prototyp» und «richtiger Software», sondern ein durchgehender Weg.
Und genau das zeigt sich auch daran, wie es danach weiterging: Was ihr heute seht, ist nicht mehr der reine Ein-Tages-Stand. Weil das Fundament trägt, konnten wir Ginolino über diesen ersten Tag hinaus laufend weiter verfeinern und optimieren. Genau das ist der Punkt eines Prototyps, der kein Wegwerf-Artefakt ist: Man baut nahtlos darauf weiter, statt bei null neu anzufangen.
Eure Idee. Ein Tag. Ein Prototyp.
Ginolino war unser eigenes Projekt, aber das Vorgehen ist genau das, was wir auch für Kundinnen und Kunden anbieten. Habt ihr eine Idee, die endlich greifbar werden soll – um sie zu testen, intern zu überzeugen oder Budget freizuschalten? Genau dafür gibt es den Prototype Sprint: An einem Tag von der Idee zu etwas, das man anfassen, bedienen und zeigen kann. Auf einem Fundament, das trägt, inklusive aller Rechte am Code.