FileMaker hat immer noch den Ruf, „die Datenbank für Nicht-Programmierer" zu sein. Wer damit aber ein gewachsenes, geschäftskritisches CRM betreut, mit Zahlläufen, Rechnungslegung und Lastschriften, die jeden Abend echtes Geld bewegen, der merkt schnell: So ein System verdient dieselbe Sorgfalt wie jedes ernsthafte Software-Projekt. Versionierung. Nachvollziehbarkeit. Werkzeuge, die dir sagen, was ein Feld wirklich anfasst, bevor du es änderst.
Genau darum habe ich mir einen Arbeitsplatz gebaut, der FileMaker mit dem verbindet, was moderne Entwicklung ausmacht. Ein kleiner Blick ins Cockpit.
Das Cockpit Sechs Flächen, jede mit einer klaren Aufgabe, kein Fenster-Chaos, sondern ein Fließband:
Oben links, FM-Lab: Der Röntgenblick in die Datenbank. Über 200.000 Objekte, durchsuchbar in Sekunden. Unten links, VS Code: Hier wird der eigentliche FileMaker-Code bearbeitet, als Textdatei, mit allem, was ein Editor kann: Syntax-Highlighting, Suchen & Ersetzen mit Regex, Multi-Cursor. Mitte, FileMaker: Die eigentliche Anwendung. Hier füge ich den bearbeiteten Code aus der Zwischenablage wieder ein, im Bild gerade zu sehen: die Raycast-Kommandozeile, die den Clipboard-Vorgang anstößt (dazu gleich mehr). Unten rechts, FileMaker-Fachansicht: Das Dashboard, wie es der Anwender sieht. Der Realitäts-Check. Oben rechts, GitKraken: Der Diff. Was hat sich geändert, Zeile für Zeile, farbig gegenübergestellt. Davor auf dem MacBook, ClickUp: Jede Erkenntnis, jeder Bug, jeder Fix wird zur Aufgabe. Nichts geht verloren. Und ganz rechts, oft übersehen: ein kleines Surface als analoger Notizzettel. Handschriftliche Stichpunkte, die Maße eines Buttons, ein schneller Ablauf-Sketch. Manche Dinge denkt man einfach schneller mit dem Stift.
Der Kern: FileMaker-Skripte gehören in Git Das größte Aha-Erlebnis für jeden, der aus der klassischen FileMaker-Welt kommt: Skripte müssen nicht in der Datei gefangen bleiben.
Möglich macht das ai2fm, die Brücke zwischen FileMakers eigenwilligem Zwischenablage-Format und sauberem, lesbarem Text. FileMaker legt beim Kopieren von Skriptschritten ein proprietäres Format in die Zwischenablage; ai2fm übersetzt das in eine klar lesbare .fmscript-Textdatei. Und, was entscheidend ist, verlustfrei wieder zurück. Erst dadurch wird der komplette Git-Workflow überhaupt möglich.
Ausgelöst wird die Umwandlung bequem per Raycast: ein Tastenkürzel, ein Befehl, genau der Moment, den man auf dem mittleren Screen sieht. Der Ablauf ist erstaunlich reibungslos:
In FileMaker das Skript kopieren (Cmd-C auf die Skriptschritte). Per Raycast den ai2fm-Befehl „FM → XML" auslösen → aus der Zwischenablage wird eine .fmscript-Datei. Diese Datei liegt in einem Git-Repository, bearbeitet, kommentiert, versioniert. Zurück denselben Weg: Raycast „XML → FM" → in FileMaker einfügen. Der Code landet 1:1 wieder im Skript. Klingt simpel, ist aber ein Paradigmenwechsel:
Jede Änderung bekommt eine Commit-Nachricht. „Warum steht das so da?" beantwortet nicht mehr das Gedächtnis, sondern die Historie. Nichts ist je verloren. Ein Fix von vor drei Wochen, ein versehentlich überschriebener Zweig, der Stand von gestern Abend vor dem Nachtlauf, alles einen Klick entfernt zurückholbar. Diffs statt Rätselraten. In GitKraken sehe ich sofort, was sich zwischen zwei Ständen geändert hat. Bei einem Skript mit hunderten Schritten ist das Gold wert. Ein Master-Zweig als Wahrheit. Streukopien mit Datum im Dateinamen? Braucht kein Mensch mehr, die Historie hält den Verlauf. Weil es reiner Text ist, funktioniert der komplette Werkzeugkasten der Softwareentwicklung: Branches für Features, Diffs fürs Review, Blame für „seit wann ist das so".
FM-Lab: die Datenbank als Nachschlagewerk Das zweite Standbein, und ein echter Gamechanger. FM-Lab, entwickelt von meinem geschätzten Kollegen Marcel More, verwandelt die gesamte FileMaker-Struktur in einen schnellen, abfragbaren Katalog. Unter der Haube läuft eine analytische Datenbank, angesprochen über eine kleine REST-Schnittstelle; das komplette Data-Design-Report-Wissen der Lösung wird eingelesen und durchsuchbar gemacht.
Ein gewachsenes CRM hat tausende Skripte, Felder, Layouts und Beziehungen, und alles hängt an allem. Die klassische Frage „Wenn ich dieses Feld ändere, was geht kaputt?" war früher eine halbtägige Handarbeit. FM-Lab beantwortet sie in Sekunden:
Where-used: Welche Skripte rufen dieses eine Skript auf? Welche Layouts zeigen dieses Feld? Abhängigkeiten: Ist dieses Berechnungsfeld nur Anzeige, oder steuert es tatsächlich einen Button, eine Buchung, eine Weiche? Muster über den ganzen Bestand: „Zeig mir jedes Skript, das einen Löschschritt enthält." Genau solche Fragen verwandeln vage Sorgen in belastbare Antworten. Der Effekt: Ich ändere nicht mehr blind und hoffe. Ich frage erst die Struktur, dann fasse ich an. Das ist der Unterschied zwischen „müsste passen" und „ist geprüft". Danke, Marcel. 🙌
Der KI-Kollege am Tisch Zwischen VS Code und Terminal sitzt ein KI-Assistent fest im Ablauf, nicht als Spielerei, sondern als Verstärker für genau diese Werkzeuge. Er liest die .fmscript-Dateien im Klartext, fragt FM-Lab nach Abhängigkeiten ab, vergleicht Live-Stand gegen Test-Stand und baut auf Wunsch Schutzmechanismen ein.
Ein typischer Moment: Ein Vorgang scheint Datensätze „verschwinden" zu lassen. Statt zu raten, gehe ich es systematisch an, den ganzen Skript-Bestand nach Löschschritten durchsuchen, die Beziehungen auf Kaskaden prüfen, die verdächtige Stelle im Skript Zeile für Zeile lesen. Am Ende steht nicht ein Bauchgefühl, sondern eine belegte Ursache und ein kleiner, gezielter Fix, mit auskommentiertem Original, damit die Historie sichtbar bleibt. Diese Diagnose-Arbeit, die früher Tage kostete, ist heute eine konzentrierte Stunde.
Alles wird zur Aufgabe Auf dem MacBook läuft ClickUp, die Klammer um das Ganze. Jeder Befund, jeder Fix, jede offene Frage wird eine Aufgabe: mit Beschreibung, betroffenen Skripten, Fälligkeit. Wenn ein Fix „spätestens bis Freitag vor dem Abendlauf" drin sein muss, steht das dort, nicht im Kopf. Und weil Commit-Nachrichten und Aufgaben dieselbe Sprache sprechen, ist die Brücke von „geplant" zu „erledigt und versioniert" nur ein Schritt.
Warum das Ganze? Weil das System, um das es geht, jeden Abend echtes Geld bewegt. Da ist kein Platz für „wird schon". Dieser Arbeitsplatz gibt mir drei Dinge, die zusammen den Unterschied machen:
Nachvollziehbarkeit: jede Änderung hat einen Grund und eine Historie. Sicherheit: ich weiß vor dem Eingriff, was dranhängt, und baue Schutz ein, statt hinterher zu reparieren. Tempo: Textwerkzeuge, Struktur-Abfragen und ein KI-Kollege machen aus Tagen Stunden. FileMaker und moderne Entwicklungsdisziplin schließen sich nicht aus. Man muss die Brücke nur bauen. Bei mir steht sie, mit ai2fm als Übersetzer, FM-Lab als Röntgenblick, Git als Gedächtnis, und sie hat sechs Bildschirme, einen Stift und einen sehr aufgeräumten Git-Verlauf.
Und der kleine Röntgenblick in die Datenbank oben links? Der hat mir schon mehr als einen stillen Fehler erspart, bevor er live gehen konnte.