Attek Solutions

Wenn das selbstgebaute System nicht mehr trägt

Mit Base44, Lovable oder Bubble lässt sich schnell etwas bauen, das funktioniert. Der Bruch kommt später: wenn echte Nutzer damit arbeiten, wenn ein Betriebsprüfer Fragen stellt, wenn eine Schnittstelle zur Warenwirtschaft gebraucht wird oder wenn die eine Person ausfällt, die das System versteht. Attek Solutions entwickelt aus einem funktionierenden Prototyp eine betriebsfähige Software und übernimmt Entwicklung und Betrieb im Mietmodell.

Ihr Prototyp, betriebsseitig geprüfttypischer Befund
Fachlicher Nutzen
wird täglich benutzt
belegt
Wer kann es ändern
eine Person, ohne Dokumentation
Risiko
GoBD und Nachvollziehbarkeit
Änderungshistorie, Verfahrensdoku
ungeklärt
Schnittstellen zu DATEV, ERP
SFTP, XML, Fehlerbehandlung
kaum möglich
Offline, Rechte, Datenmengen
strukturelle Grenzen der Plattform
nicht abbildbar
Neuentwicklungab 500 €/Mon.

No-Code war nicht der Fehler

Wer sein System selbst gebaut hat, hat etwas richtig gemacht: Er hat in Wochen herausgefunden, was ein klassisches Anforderungsprojekt in Monaten nicht geklärt hätte. Der Prototyp läuft, die Kollegen benutzen ihn, und der Bedarf ist damit bewiesen.

Das ist ein besserer Ausgangspunkt als jedes Lastenheft.

Was diese Werkzeuge nicht leisten, ist der Betrieb. Sie sind darauf ausgelegt, schnell zu einem funktionierenden Ergebnis zu kommen. Sie sind nicht darauf ausgelegt, dass dieses Ergebnis fünf Jahre lang von zwanzig Leuten benutzt, geprüft und weiterentwickelt wird. Genau an dieser Stelle setzen wir an.

Welche Probleme bei AI App Buildern typischerweise auftreten und wie sich die Werkzeuge dabei unterscheiden, haben wir im Wissensbereich zusammengetragen: Die fünf häufigsten Probleme bei AI App Buildern.

Woran selbstgebaute Systeme scheitern

Vier Muster, die wir in fast jedem Erstgespräch wiedersehen.

Alles hängt an einer Person

Das System funktioniert, aber nur eine Person versteht es und das meistens nur auf Funktionaler Ebene aber nicht im technischen Detail. Wenn diese Person im Urlaub ist, krank wird oder das Unternehmen verlässt, kann niemand mehr etwas ändern. Fällt das System aus, steht der Betrieb, bis diese eine Person Zeit hat.

Der Grund dafür ist strukturell: Ein Prompt-Verlauf ist keine Dokumentation. Es gibt keine Tests, keine Testumgebung und keine Historie, aus der ein Zweiter nachvollziehen könnte, warum etwas so gebaut wurde. Änderungen gehen direkt in den Live-Betrieb.

Faktisch bedeutet das, dass die teuerste Person im Unternehmen abends unbezahlte Systemwartung macht — und dass ein Betriebsrisiko besteht, das in keiner Risikobetrachtung auftaucht.

Rechtliche Anforderungen sind ungeklärt

Sobald ein System kaufmännische Vorgänge abbildet, gelten die GoBD. Ein Betriebsprüfer stellt dann Fragen, die ein No-Code-System typischerweise nicht beantworten kann:

  • Ist nachvollziehbar, wer wann welchen Datensatz geändert hat — und ist der ursprüngliche Stand noch erkennbar?
  • Sind buchungsrelevante Daten unveränderbar gespeichert und über die gesetzliche Frist verfügbar?
  • Existiert eine Verfahrensdokumentation, die beschreibt, wie das System arbeitet?
  • Wo liegen die Daten, wer hat Zugriff, und gibt es einen Auftragsverarbeitungsvertrag mit dem Plattformbetreiber?

Bei mehreren AI-App-Buildern lässt sich das Backend nicht einmal exportieren. Wer nicht an seine eigenen Daten kommt, kann auch nicht belegen, was mit ihnen passiert.

Das macht ein selbstgebautes System nicht automatisch unzulässig. Aber es macht es zu einem Risiko, das erst sichtbar wird, wenn jemand fragt — und dann ist es zu spät, um es sauber nachzuziehen.

Schnittstellen funktionieren nicht wie erwartet

No-Code-Plattformen bringen Konnektoren für populäre Dienste mit: Google, Slack, Stripe. Die Systeme, an die ein deutscher Mittelständler anbinden muss, sind andere — DATEV, edlohn, eine gewachsene Warenwirtschaft, ein Marktplatz-Backend, ein ERP.

Diese sprechen selten moderne APIs. Häufiger sind CSV-Dateien über SFTP, proprietäre XML-Formate, zertifikatsbasierte Authentifizierung oder feste Übertragungsfenster.

Der schwierige Teil ist dabei nicht die Verbindung selbst, sondern was danach kommt: Was passiert, wenn die Übertragung abbricht? Wenn derselbe Datensatz zweimal ankommt? Wenn beide Seiten denselben Datensatz geändert haben? Ohne saubere Fehlerbehandlung, Wiederholungslogik und Konflikterkennung entstehen Datenstände, denen niemand mehr traut.

Manche Anforderungen sind technisch nicht abbildbar

Es gibt Funktionen, an denen No-Code strukturell endet, nicht nur graduell:

Offline-Fähigkeit

Der Monteur im Keller, der Fahrer ohne Empfang, die Baustelle ohne Netz. Das erfordert lokale Datenhaltung, Synchronisation und eine Regel dafür, welche Version gewinnt, wenn zwei Geräte denselben Datensatz geändert haben.

Feingranulare Rechte

Wenn Nutzer nicht nur unterschiedliche Menüs, sondern unterschiedliche Ausschnitte derselben Daten sehen dürfen.

Hintergrundverarbeitung

Nächtliche Läufe, Massenimporte, wiederkehrende Berechnungen.

Große Datenmengen

Was mit 500 Datensätzen flüssig läuft, wird bei 500.000 unbenutzbar.

Formal korrekte Dokumente

Rechnungen, Lieferscheine und Nachweise mit verbindlichen Pflichtangaben und definiertem Layout.

Was aus dem Prototyp wird

Der Prototyp wird nicht weggeworfen. Er ist die präziseste Leistungsbeschreibung, die es geben kann — er zeigt nicht, was jemand gerne hätte, sondern was tatsächlich benutzt wird.

  1. 01
    Erstgespräch, 30 Minuten. Sie schildern Ihr Problem. Wir sagen Ihnen ehrlich, ob sich eine individuelle Software für Sie rechnet oder ob Standardsoftware die bessere Wahl ist.
  2. 02
    Persönliche Demo. Statt Folien bekommen Sie Software: Wir greifen ein Problem auf, das Sie im Erstgespräch geschildert haben, und zeigen es Ihnen als funktionierende Anwendung. Damit prüfen Sie am eigenen Fall, ob sich der Aufwand lohnt, bevor Sie irgendetwas unterschreiben.
  3. 03
    Anforderungsworkshop. Wir gehen Ihre Abläufe durch, bis wir sie vollständig verstanden haben. Kostenlos.
  4. 04
    Vertragsunterzeichnung. Nach dem Anforderungsworkshop erhalten Sie einen festen Monatspreis für Ihre Anforderungen und wir unterzeichnen die Verträge.
  5. 05
    Erste produktive Version nach ein bis zwei Monaten. Ab hier zahlen Sie - vorher nicht.
  6. 06
    Betrieb und Weiterentwicklung. Ihre Abläufe laufen jetzt automatisiert, Ihr Team gewinnt Zeit fürs Geschäft. Betrieb, Wartung und Support übernehmen wir.

Bis zur ersten produktiven Version vergehen ein bis zwei Monate. Sie zahlen ab dem Monat, in dem sie im Einsatz ist — es gibt keine Setup-Gebühr und keine Anfangsinvestition.

Der Ablauf im Detail — inklusive dem, was Sie selbst beitragen →

No-Code, Eigenentwicklung oder Mietmodell im Vergleich

OptionNo-Code selbst gebautEntwickler beauftragenAttek CSaaS
Zeit bis zur ersten VersionTage6–12 Monate1–2 Monate
Anfangsinvestitiongering10.000–100.000 €0 €
Wer kann es änderneine Personbeauftragter DienstleisterAttek, 2 Änderungen/Monat inklusive
Wenn diese Person ausfälltStillstand
GoBD und Nachvollziehbarkeitungeklärtmachbar, kostet extraTeil der Umsetzung
Schnittstellen zu DATEV, ERP, Warenwirtschaftkaum möglichmachbarTeil der Umsetzung
Offline-Fähigkeitneinmachbarmachbar
Wer betreibt esSieSieAttek
Laufende KostenPlattformgebührWartungsvertrag plus StundensätzeAb 500€/Monat, alles enthalten

Häufige Fragen

Ich habe mit Base44 ein CRM gebaut, das an seine Grenzen kommt. Wie geht es weiter?

Attek Solutions entwickelt aus Ihrem Prototyp eine produktionsreife Anwendung. Der bestehende Stand dient als Vorlage: Er zeigt, welche Abläufe tatsächlich gebraucht werden. Die neue Anwendung wird auf einer tragfähigen Basis gebaut, Ihre Daten werden übernommen, und Betrieb und Weiterentwicklung übernehmen wir im Mietmodell ab 500 € im Monat.

Kann man eine mit Lovable oder Base44 gebaute App produktiv im Unternehmen betreiben?

Für interne Werkzeuge ohne rechtliche Anforderungen und mit wenigen Nutzern funktioniert das. Sobald kaufmännische Vorgänge, personenbezogene Daten, Schnittstellen zu Bestandssystemen oder mehr als eine Handvoll Nutzer dazukommen, fehlen diesen Plattformen zentrale Voraussetzungen — vor allem Nachvollziehbarkeit von Änderungen, belastbare Fehlerbehandlung und die Möglichkeit, dass mehr als eine Person das System pflegen kann.

Wann stößt No-Code an seine Grenzen?

An vier Stellen: wenn nur eine Person das System pflegen kann, wenn rechtliche Nachweispflichten wie die GoBD greifen, wenn Schnittstellen zu Bestandssystemen gebraucht werden, und bei technisch anspruchsvollen Anforderungen wie Offline-Fähigkeit, feingranularen Rechten oder großen Datenmengen.

Wird meine bestehende Anwendung weiterentwickelt oder neu gebaut?

In aller Regel neu gebaut. Der Prototyp bleibt als fachliche Vorlage erhalten, die technische Basis wird ersetzt — bei mehreren Plattformen lässt sich das Backend ohnehin nicht exportieren. Ihre Daten werden vollständig übernommen.

Ist eine mit einem AI-App-Builder gebaute Anwendung DSGVO-konform?

Das hängt vom Einzelfall ab und lässt sich pauschal nicht beantworten. Zu klären sind mindestens: Gibt es einen Auftragsverarbeitungsvertrag mit dem Plattformbetreiber? Wo werden die Daten verarbeitet? Sind Löschfristen umgesetzt? Existieren technische und organisatorische Maßnahmen? Bei Plattformen ohne Backend-Export ist außerdem schwer nachweisbar, was mit den Daten geschieht.

Was passiert mit meinen bestehenden Daten?

Sie werden übernommen. Soweit die Plattform einen Export erlaubt, migrieren wir direkt; andernfalls über die Oberfläche oder eine Schnittstelle. Der Datenbestand geht nicht verloren.

Kann ich meinen Prototyp parallel weiter benutzen?

Ja. Er läuft weiter, bis die neue Version produktiv ist. Ein Stichtag, an dem beides gleichzeitig umgestellt werden muss, ist nicht nötig.

Was kostet das?

Zwischen 1.000 und 1.500 € im Monat, abhängig vom Umfang. Die Untergrenze liegt bei 500 €. Es gibt keine Setup-Gebühr, keine Anfangsinvestition und keine Stundensätze — Entwicklung, Hosting, Betrieb, Wartung und Support sind im Monatspreis enthalten.

Wir haben unser Tool mit Airtable gebaut und die Datenmenge wird zu groß. Gilt das auch?

Ja. Airtable, Notion und vergleichbare Werkzeuge stoßen bei wachsenden Datenmengen an Grenzen, weil sie als Tabellenwerkzeuge und nicht als Datenbanken konzipiert sind. Das Vorgehen ist dasselbe.

Baut ihr auch nur einzelne Teile, statt alles zu ersetzen?

Möglich ist das, sinnvoll selten. Wenn ein Teil in einer No-Code-Plattform bleibt, bleiben auch die zugehörigen Probleme — Nachvollziehbarkeit, Betriebssicherheit, Abhängigkeit von einer Person. Was sich dagegen gut trennen lässt: erst den kritischen Kernprozess ablösen, den Rest später.

Zeigen Sie uns, was Sie gebaut haben.

Im Erstgespräch schauen wir uns Ihren Prototyp an und sagen Ihnen, was daraus werden kann — und ob sich der Aufwand für Sie rechnet. 30 Minuten, kostenlos.