Ein CRM mit Airtable

Eigentlich geht es bei uns in der Nachbarschaft um Wärme. Um ein Nahwärmenetz, um eine gemeinsame Heizlösung, um ein Projekt, das ökologisch sinnvoll ist und langfristig unabhängig macht. Ganz praktisch heißt das aber auch: 40 Haushalte müssen überzeugt, informiert und koordiniert werden. Und relativ schnell wurde klar: Mit Zetteln, E‑Mails und Bauchgefühl kommt man hier nicht weit. Also habe ich mir ein kleines System gebaut.

Vom Heizungsprojekt zur Datenbankanwendung

Was als einfache Liste begann, wurde schnell strukturierter. Haushalte, Straßen, Bewohner, Vermieter. Dazu Aufgaben, Gespräche, Rückmeldungen. Klassisches CRM – nur eben nicht für Sales, sondern für Nachbarschaft.

Jeder Haushalt hat einen Status: Erstkontakt, interessiert, Rückfragen, Entscheidung offen, dabei, abgesprungen. Daraus entsteht ganz automatisch eine Pipeline. Eine Kanban‑Sicht, die auf einen Blick zeigt, wo wir stehen.

Nicht, weil ich fancy Software bauen wollte. Sondern weil Komplexität sonst unkontrollierbar wird. Nein, eigentlich doch, weil ich fancy Software bauen will. Weil ich es kann. Und weil es aktuell so einfach ist wie nie, Full Custom Apps zusammenzuzimmern.

Airtable als Tech‑Stack: Begeisterung und Ernüchterung

Technisch basiert das Ganze auf Airtable. Und ja: Airtable ist schon ziemlich cool.

Das Datenmodell ist schnell gebaut, Beziehungen sind klar, Views flexibel. Kanban‑Pipeline? Ein Klick. Statistiken? Ein paar Formeln. Interfaces für Mitstreiter? Auch machbar.

Die Usability dieser Interfaces ist okay. Sie reicht für Leute wie mich, die sich täglich in datenbasierten Anwendungen bewegen. Für Nachbarn, die einfach nur wissen wollen, wer dran ist und was als Nächstes passiert, ist es aber noch keine Premium‑UX. Zu viele Tabellen, zu viel implizite Logik, zu viel „Datenbank‑Gefühl“.

Es funktioniert. Aber es fühlt sich nie ganz selbstverständlich an.

Lock‑in ist kein theoretisches Problem

Der größere Dämpfer kam beim Thema Skalierung. Im Free‑Account sind fünf User enthalten. Danach wird es schnell ernst: rund 20 Dollar pro Nutzer und Monat.

Ich zahle gern für gute Software. Wirklich. Aber hier merkt man plötzlich, wie hart der Lock‑in zuschlägt. Das System ist gebaut, die Daten sind drin, die Workflows stehen – und jeder weitere Mitstreiter kostet.

Für ein Nachbarschaftsprojekt ist das schlicht zu viel. Skalierbarkeit ist hier kein Feature, sondern eine Grenze.

KI‑generierte Apps: ernüchternd räudig

Ich habe auch mit der KI‑Unterstützung experimentiert. „Bau mir eine App“, „erzeuge mir ein Interface“, „mach das wie ein CRM“. Was man von Tools wie Lovable kennt.

Meine Erfahrung: Das Ergebnis ist meist räudig.

Strukturen wirken zufällig, Benennungen unsauber, Logik inkonsistent. Man spart vielleicht Zeit beim Klicken, verliert sie aber beim Aufräumen, Nachdenken und Korrigieren. Hab schnell die Finger davon gelassen.

Fazit

Das kleine CRM hat seinen Zweck erfüllt. Es hat Struktur geschaffen, Übersicht gebracht und das Projekt vorangebracht.

Gleichzeitig zeigt es sehr deutlich die Grenzen solcher Tools: Usability für Nicht‑Techies, harte Preisstufen, starker Lock‑in.

Meine wichtigste Erkenntnis: Low‑Code macht es leicht, Systeme zu bauen. Aber nicht unbedingt leicht, die richtigen Systeme langfristig zu betreiben.

Und genau an dieser Stelle wird aus einem Nachbarschaftsprojekt plötzlich wieder echte Softwareentwicklung.

Ausblick

Ich schaue mir als Nächstes mal Supabase an. Self‑hosted per Docker, die Daten bei mir, keine „pro User“-Strafsteuer für ein paar helfende Hände.

Und wenn das Backend steht, ist der nächste Gedanke natürlich: ein kleines Next.js‑Frontend davor. Genau so, wie man es eigentlich schon immer bauen wollte – nur dass es sich heute nicht mehr nach drei Monaten Projektplan anfühlt, sondern nach einem Wochenende mit einer Kanne Kaffee.

Ich merke, wie schnell ich dabei wieder in diesen Zustand rutsche: leichtes Hype‑Gefühl, weil plötzlich wieder alles möglich wirkt.

Vielleicht ist das die eigentliche Lehre: Tools wie Airtable sind super, um schnell Klarheit zu gewinnen. Aber wenn ein Projekt wirklich läuft, fängt man früher oder später doch wieder an, sich sein eigenes System zu bauen.