Gestern um 22 Uhr hatte ich eine vage Idee, ein Directus Deployment in einen Sales Asset zu verwandeln. Heute Morgen um 7 Uhr hatte ich einen funktionierenden Admin auf Railway, drei live Dashboards, einen öffentlichen Demo Blog mit fünf Posts, eine 2.400-Wort-Sales Pillar, die die ganze Geschichte als Service verkauft, und drei Production Bugs, die ich um Mitternacht erwischt und behoben habe. Die gesamten Infrastrukturkosten: 5 Dollar pro Monat. Die gesamte Zeit: ungefähr neun Stunden konzentrierter Arbeit verteilt auf eine Nacht und einen frühen Morgen.
Das ist die Case Study. Was gebaut wurde, was kaputtging, was ich gelernt habe, und die echten Zahlen hinter dem Build. Falls du evaluierst, ob du ein ähnliches Projekt für dein Business in Auftrag geben solltest, sind die Datenpunkte unten die ehrlichste Referenz, die ich dir bieten kann.
Was ich mir vorgenommen habe
Drei Ziele, in Prioritätsreihenfolge.
Erstens, Directus mit meiner bestehenden Supabase Postgres Datenbank verbinden. Ziel: ein generischer CRUD Admin, der auf die gleichen Daten zeigt, die mein benutzerdefinierter Astro Admin bereits verwaltet. Grund: nicht, um den benutzerdefinierten Admin zu ersetzen (der Monday-style Inline Editing hat, das dem Team gefällt), sondern um die Operations Layer hinzuzufügen, die der benutzerdefinierte Admin nicht hat. Bulk Edits, gespeicherte Views, rollenbasierte Permissions, Schema Browser, Insights Dashboards.
Zweitens: Ich richte die Dashboards ein, die ich seit sechs Monaten haben wollte. Drei Boards: Content Pipeline (Blog-Publishing-Geschwindigkeit, Themen-Queue-Tiefe), SEO-Gesundheit (Rank-Positionen, AI-Overview-Präsenzrate, Intent-Verteilung), Tool-Nutzung (AEO-Tool-Suchen, Brand-Name-Tool-Suchen, Advisor-Nutzung). Konkrete Zahlen, die ich montags auf einen Blick sehe, um zu wissen, ob die Engine läuft.
Drittens: Das ganze Projekt in ein Sales-Asset verwandeln. Der Directus-Admin, den ich für mich selbst deploye, ist identisch mit dem, den ich für einen Client deployen würde. Das Deployment selbst wird also zur Demo. Ein potenzieller Client klickt auf meiner Sales-Page auf einen Button, landet in einem echten Directus-Admin mit echten Daten, tippt in den Rich-Text-Editor, sieht, wie gespeicherte Views funktionieren, und kommt dann zurück, um einen Call zu buchen. Gesamte Demo-Loop-Reibung: etwa fünfzehn Sekunden vom Page-Land bis zum Live-Editor.
Stunde 0 bis 4: Deployment
Railway Hobby-Plan, offizielles Directus-Template, One-Click-Deploy. Das Template wird mit Directus plus Redis plus einer gebündelten PostGIS-Datenbank plus einem S3-kompatiblen Storage-Bucket ausgeliefert. Gesamte Deploy-Zeit einschließlich Konfiguration: 35 Minuten von leerem Railway-Konto bis eingeloggter Admin.
Die erste Überraschung: Das Directus-Template verdrahtet seine Datenbankverbindung über Referenzvariablen, die auf den gebündelten PostGIS-Service zeigen, nicht über einzelne Host-/Port-/User-/Password-Felder. Um Directus auf meine externe Supabase Postgres umzuleiten, musste ich die Connection-String-Variable (DB_CONNECTION_STRING) finden und meine Supabase Session Pooler URL mit Anmeldedaten einfügen.
Die zweite Überraschung: Mein Supabase-Datenbankpasswort enthielt das Zeichen „#". URL-codiert als %23 in einem Postgres-Connection-String. Ohne Codierung schneidet der URL-Parser die String am # ab, weil Hash ein URL-Fragment bedeutet. Directus protokollierte ECONNREFUSED::1:5432, weil es auf localhost zurückfiel, wenn der Connection-String malformed war. Eine halbe Stunde Verwirrung, dann habe ich das Passwort auf alphanumerisch-nur rotiert und die Verbindung funktionierte.
Sobald Directus verbunden war, wurden alle 12 Tabellen aus meiner Supabase-Datenbank automatisch als Directus Collections importiert. Zero Schema Migration, null Datenbewegung, null Downtime. Der Custom-Astro-Admin und der Directus-Admin sehen beide die gleichen Daten, beide schreiben sie, beide reflektieren sofort gegenseitige Änderungen.
Stunde 4 bis 12: Konfigurieren, konfigurieren, konfigurieren
Der Großteil der Arbeit war nicht das Deployment. Es war Field-Level-Konfiguration, um Directus wie einen polished Admin statt wie einen rohen Database Browser zu verhalten. Jede Spalte braucht Interface-Metadaten, Display-Formatierung, Sortierreihenfolge, Breite, Gruppe und Visibility-Entscheidungen. Standard-Directus zeigt alles; die polished Version zeigt nur, was das Team braucht.
Drei Beobachtungen aus dieser Phase.
Das Ganze über die Directus Admin-UI per Klick zu erledigen ist langsam. Grob zwei Minuten pro Feld, neunzig-plus Felder über zwölf Collections, Gesamtklick-Zeit knapp drei Stunden. Ich habe es an einen Browser-steuernden AI-Agent delegiert (Claude in Chrome), der auf die Directus REST API für Bulk-Konfiguration gewechselt hat. Der Agent hat PATCH /fields/{collection}/{field} Calls sequenziell gepostet, mit dem vollständigen Meta-Objekt als Payload. Drei Minuten pro Collection statt vierzig. Die ganze Config-Phase komprimierte sich von drei Stunden auf vierzig Minuten.
Der REST-API-Ansatz gab mir auch Reproduzierbarkeit. Jedes PATCH ist ein curl-Äquivalent, das ich auf einer frischen Directus-Deployment erneut ausführen könnte, um dieselbe Konfiguration wiederherzustellen. Die Konfiguration ist effektiv Code, nicht ein fragiles Häufchen von UI-Klicks.
Das letzte Viertel dieser Phase war das Bauen der drei Insights-Dashboards. Jedes Panel ist eine JSON-Config, die an POST /panels gesendet wird. Die Dashboards landeten in grob zwanzig Minuten, sobald die Feld-Metadaten vorhanden waren. Drei Boards, sechs Panels, echte Daten rendern. Die Zahlen, die ich sechs Monate lang geraten hatte, waren endlich auf dem Bildschirm.
Stunde 12 bis 18: die drei Bugs, die die meiste Zeit gekostet haben
Kein Build ist real, bis er in Production bricht. Drei Bugs tauchten auf, nachdem ich zu Main shipped und die Live-Site refreshed hatte.
Bug 1: Spline-Szene blockiert durch CSP, mit drei gestapelten Ursachen
Ich hatte auch eine 3D-first Web-Säule mit einem Spline NEXBOT-Roboter-Hero shipped. Nach dem Deploy war der Roboter in Production unsichtbar, funktionierte aber lokal. Drei gestapelte Probleme in Folge.
Eins: das Script-Tag mit define:vars wurde von Astro inline gemacht, was bedeutete, dass Vite den Dynamic Import von @splinetool/viewer nicht bundelte, was bedeutete, dass der bare Module Specifier im Browser nicht auflösbar war. Zwei: nach dem Beheben dessen war das spline-viewer-Element in einem Parent mit dem hidden-Attribut zur Upgrade-Zeit, sodass das Lit Custom Element mit 0x0-Dimensionen initialisiert wurde und sich nie erholte. Drei: nach dem Beheben dessen fetched der Spline Viewer sein Modelling WASM von unpkg.com zur Scene-Load-Zeit, welches mein CSP nicht whitelistete. Jede Behebung surfaced den nächsten Bug. Gesamtdebug-Zeit: neunzig Minuten.
Production-only-Debugging ist seine eigene Disziplin. Der Dev-Server löst bare Imports anders auf als der Production Build. Die Dev-Umgebung hat ein permissiveres Standard-CSP. Beide Bugs waren unmöglich zu surfacen ohne einen echten Production-Deploy. Meine Erkenntnis: ship in eine echte Umgebung früh, auch wenn lokal alles funktioniert.
Bug 2: AI Overview boolean und Postgres avg()
Ein Insights-Panel sollte zeigen, „welcher Prozentsatz der verfolgten SERP-Läufe einen AI Overview anzeigt." Die Tabelle seo_serp_runs hat eine boolesche Spalte ai_overview_present. Naiver Instinkt: avg() über diese Spalte, mal 100 multiplizieren, als Prozentsatz rendern.
Postgres wirft einen Fehler bei avg(boolean). Die Funktion existiert für diesen Typ nicht. Mehrere Workaround-Versuche schlugen fehl: Directus stellt kein „percentage"-Aggregat bereit, count-of-true mit hartcodiertem Nenner driftet ab, wenn mehr Zeilen hinzukommen, das Casting zur Abfragezeit wird nicht durch die Insights-Panel-Optionen bereitgestellt.
Der Fix, der funktionierte: eine generierte Spalte ai_overview_present_int hinzufügen, die als case when ai_overview_present then 100 else 0 end berechnet wird. avg() über eine Integer-Spalte funktioniert trivial und liefert direkt den Prozentsatz. Eine SQL-Migration in einer Zeile, null Änderungen am Application-Code.
Bug 3: Image-Hosts in CSP
Ich habe das Demo-Blog mit fünf Unsplash-Foto-URLs gefüllt. Der Browser hat sie stillschweigend blockiert, weil images.unsplash.com nicht in img-src gewhitelistet war. Schwarze Bilder auf der öffentlichen Demo-Blog. Ich habe Unsplash zu CSP hinzugefügt, die Bilder wurden gerendert, dann realisierte ich, dass ich meine eigene unverhandelbare Regel gerade verletzt hatte, alle in Supabase Storage gespeicherten Bilder mit FAL zu verwenden.
Richtiger Fix: ein Script, das jede demo_posts-Zeile abruft, pro Kategorie ein redaktionelles Foto via FAL flux-pro/v1.1-ultra generiert, mit sharp zu WebP bei Qualität 82 und max-width 1600 neu encodiert, in einen öffentlichen Supabase-Storage-Bucket hochlädt und featured_image auf die Storage-CDN-URL aktualisiert. Zwanzig Minuten Build, fünf FAL-Generationen kosten unter einem Pfund. Unsplash aus CSP entfernt. Bilder leben jetzt in meiner eigenen Infrastruktur, keine externen Dependencies, kein CSP-update-per-host-Laufband in Zukunft.
Stunde 18 bis 24: die Sales-Säule
Mit funktionierendem Directus und richtig gerendertem Demo-Blog schrieb ich die Sales-Säule unter /solutions/headless-cms-and-admin-tools/. Vier Service-Tiers (CMS, Internal Ops Admin, Directories, Bespoke), in USD mit GBP in Klammern preisgegeben, sechs FAQs, eine Vergleichstabelle gegen WordPress und HubSpot und Notion und Airtable, ein „Brief I will not take"-Abschnitt, um die falsch geformten Clients früh auszusortieren.
Die Säule verlinkt direkt auf die Live-Demo. Prospects, die auf „OPEN THE EDITOR" klicken, landen in der echten Directus-Admin mit angezeigten Credentials, die sie einfügen. Sekunden später bearbeiten sie einen echten Post in einem echten Editor. Die Demo-Loop dauert fünfzehn Sekunden von Page-Land bis zur Live-Bearbeitung.
Gesamtzeit auf der Pillar-Seite: neunzig Minuten Schreiben plus dreißig Minuten Schema-Markup, interne Links und visuelles Polish. Die Seite selbst brauchte weniger Zeit als zwei der drei Bugs.
Zahlen
Kostenaufschlüsselung des Builds, da dies der Case-Study-Post ist und das die Frage ist, die Interessenten stellen werden.
Railway Hobby-Plan für Directus + Redis + Bucket: $5 pro Monat, monatliche Abrechnung. Erste 30 Tage kostenlos.
Supabase Postgres: vorhandene Infrastruktur, keine neuen Kosten. Nutze bereits den Pro-Plan mit ungefähr $25 pro Monat für die Datenbank.
FAL API für fünf Hero-Bilder: unter ein Pfund insgesamt, ungefähr $1 USD.
DataForSEO zum Befüllen von 42 Keywords mit Suchvolumen + Intent + Schwierigkeit: $0,04 insgesamt.
Meine Zeit, von Anfang bis Ende inklusive Bugs und Schreiben: neun Stunden konzentrierte Arbeit. Bei meinem Beratungs-Tagessatz von ungefähr $1.500 pro Tag sind das ungefähr $1.700 an Opportunitätskosten.
Gesamtausgaben in bar zum Versand des funktionierenden Sales-Assets: ungefähr $6 für inkrementelle Infrastruktur plus $1 für API-Gebühren. Gesamtkosten inklusive Zeit: ungefähr $1.700.
Vergleich als Referenz: Eine Agentur, die ein „Headless-CMS-Admin-Tool-Build"-Engagement angeboten hätte, würde typischerweise $8.000 bis $15.000 USD für den äquivalenten Umfang berechnen. Ich berechne $8.000 bis $19.000 USD auf meiner eigenen Service-Seite. Die Spanne zwischen Kosten-zum-Bauen und Preis-zum-Verkaufen ist das gesamte wirtschaftliche Triebwerk der Agenturarbeit. Die Case Study ist der Beweis, dass die Kosten-zum-Bauen-Zahl real ist.
Was dies einem potenziellen Kunden beweist
Drei Dinge, alle überprüfbar in den nächsten zehn Minuten.
Erstens: Der Build ist real. Klicke auf den OPEN THE EDITOR Button auf der Sales Page. Tippe in den Rich-Text-Editor. Plane einen Post ein. Schaue dir die Dashboards an. Das Ding existiert. Es ist kein Mockup, es ist keine Figma-Datei, es ist kein Screenshot. Es ist die gleiche Software, die ich für dein Business deployen würde.
Zweitens: Die Speed ist real. Vierundzwanzig Stunden von „vager Idee" bis „in Produktion deployed Sales Asset mit Live Demo." Eine Client Engagement würde sich nicht in dieser Geschwindigkeit bewegen, weil Client Engagements Discovery, Design Review, Stakeholder Approvals und Security Audits enthalten. Aber die zugrunde liegende Build Velocity ist das, was bestimmt, ob eine Sechs-Wochen-Timeline ehrlich oder optimistisch ist. Vierundzwanzig Stunden Solo-Build-Aufwand entsprechen ungefähr drei Wochen Standard-Agency-Engagement-Zeit, wenn der Overhead eingerechnet ist. Diese Mathematik ist das, was die Sechs-bis-Acht-Wochen-Tier-1-Timeline produziert.
Drittens: Die Failure Modes sind real. Drei Production Bugs wurden in Echtzeit gefunden und behoben. CSP Issues, Dynamic-Import Bundling, Generated-Column Arithmetic. Das sind die gleichen Bugs, die in Client Engagements auftauchen. Die Tatsache, dass ich sie auf einer Live Site gefangen und behoben habe, ist die tatsächliche Demo von Kompetenz. Eine polierte Case Study ohne Bugs wäre die verdächtige.
Was ich anders machen würde
Drei kleine Überlegungen, in Reihenfolge der Nützlichkeit.
Ich hätte mit dem FAL Image Generation Script angefangen, bevor ich zum Unsplash Workaround griff. Der CSP-Update-dann-Revert-Tanz kostete zehn Minuten unnötiger Churn. Die unverhandelbare Regel über FAL Images existiert genau deswegen und ich hätte zuerst auf sie hören sollen.
Ich hätte vom Start weg den REST API Ansatz für die Directus Konfiguration verwendet, statt die UI Click-Through zu versuchen. Die Agent-gesteuerte REST-Call-Sequenz war drei Mal schneller und produzierte reproduzierbare Konfiguration. Die Lektion verallgemeinert sich über Directus hinaus: Jeder Admin, der eine umfassende REST API exponiert, sollte durch diese API konfiguriert werden, statt durch sein UI.
Ich hätte den Case-Study Post früher geschrieben. Dieser Post wird etwa zwölf Stunden nach Ende des Builds geschrieben. Zu dem Zeitpunkt, an dem ich das schreibe, verblassen einige der Failure Modes bereits aus dem Gedächtnis. Die ehrliche Case Study ist die, die am gleichen Tag wie der Build geschrieben wird, während die Bugs noch frisch genug sind, um sie genau zu beschreiben.
Wo es als Nächstes hingeht
Wenn Sie evaluieren, ob Ihr Unternehmen einen ähnlichen Build in Auftrag geben sollte, ist die Demo-Schleife der schnellste Weg zu einer aussagekräftigen Antwort. Öffnen Sie /solutions/headless-cms-and-admin-tools/, klicken Sie auf den Demo-Button, melden Sie sich mit den angezeigten Anmeldedaten an, verbringen Sie fünfzehn Minuten damit, herumzuklicken. Am Ende haben Sie ein klares Verständnis dafür, ob diese Art von Tool zu Ihrem Team passt oder nicht.
Wenn ja, buchen Sie den dreißigminütigen Anruf, der auf dieser Seite verlinkt ist. Erzählen Sie mir von Ihrem bestehenden Stack, Ihrer Team-Größe, Ihrer Datenstruktur. Am Ende des Anrufs haben Sie eine Tier-Wahl, eine Preisspanne und ein Lieferfenster. Die meisten Projekte, die ich übernehme, laufen sechs bis zwölf Wochen bei $8.000 bis $50.000 USD, je nach Umfang. Die Hälfte, die ich nicht übernehme, erkläre ich Ihnen auf dem Anruf.
Wenn Sie die vollständige Sales Pitch wünschen, finden Sie die Pillar Page unter /solutions/headless-cms-and-admin-tools/. Wenn Sie direkt zur Live-Demo springen möchten, finden Sie die Anmeldedaten auf dieser Seite. Wenn Sie die nächste Fallstudie wünschen, wird der nächste Blog-Post wahrscheinlich entweder über einen Build für einen asiatischen Korridor-Hersteller oder das gleiche Muster angewendet auf ein anderes Geschäftsfeld handeln. Sagen Sie mir, welche Option hilfreicher ist.