ERP für Vibe Coding

Eine eigene Anwendung entsteht heute in Stunden statt in Wochen – man beschreibt sie einem KI-Modell, und das schreibt den Code. Was dabei fehlt, ist selten die Oberfläche. Es sind die Daten dahinter. Genau die bringt projectfacts mit, über eine offene Schnittstelle und mit den Rechten, die bei Ihnen ohnehin gelten.

14 Tage Test

Was ist ein ERP für Vibe Coding?

Vibe Coding bezeichnet das Programmieren im Dialog mit einer KI: Man beschreibt in normaler Sprache, was ein Programm tun soll, das Modell schreibt den Code dazu. Ein ERP für Vibe Coding ist entsprechend eine Unternehmenssoftware, deren Daten und Abläufe über eine dokumentierte Schnittstelle bereitstehen – so dass auf dieser Grundlage eigene Anwendungen entstehen können, ohne dass jemand Kundenverwaltung, Projekte, Zeiterfassung oder Abrechnung neu bauen müsste.

projectfacts kann diese Rolle übernehmen. Über die REST-API greift eine selbstgebaute Anwendung auf dieselben Daten zu, mit denen Ihre Mitarbeiter in der Oberfläche arbeiten. Die Anmeldung läuft über ein Gerätepasswort, das ein Benutzer sich in projectfacts selbst erzeugt. Und es gilt dabei eine Regel, die alles Weitere einfacher macht: Über die Schnittstelle – und damit auch in der eigenen Anwendung – hat jemand genau die Rechte, die er in projectfacts ohnehin hätte. Keine mehr.

Was projectfacts dafür mitbringt

Eine offene Schnittstelle

Kontakte, Projekte, Aufgaben, Zeiten, Tickets und Belege lassen sich lesen und anlegen – über feste Adressen mit beschriebenen Feldern.

Beschriebene Felder

Ein Modell schreibt nur brauchbaren Code, wenn es die Gegenstelle kennt. Aufbau der Adressen, Formate und Feldreferenzen stehen in der OpenAPI-Beschreibung des Servers und im Hilfecenter.

Ihre Rechte gelten weiter

Die eigene Anwendung sieht nur, was der angemeldete Benutzer auch in projectfacts sehen darf. Ein eigenes Rechtesystem gibt es nicht.

Eine Oberfläche für alle passt selten allen

Eine Unternehmenssoftware deckt viele Aufgaben ab und zeigt deshalb viel. Der einzelne Mitarbeiter braucht davon oft nur einen schmalen Ausschnitt – und zwar jeder einen anderen.

Der Monteur draußen

Kunde auswählen, Auftrag öffnen, Zeit starten, Foto anhängen, fertig. Fünf Handgriffe auf einem Handy, bei schlechtem Empfang, mit Handschuhen.

Die Projektleitung

Meine Projekte, offene Punkte, gebuchte Zeiten, verbleibendes Budget. Eine Übersicht, die morgens in zwanzig Sekunden gelesen ist.

Die Geschäftsführung

Umsatz, Auslastung, offene Rechnungen. Wenige Zahlen, groß genug für den Blick zwischen zwei Terminen.

Was daraus folgt

Nicht jeder muss mit derselben Oberfläche arbeiten. Wo eine eigene, auf einen Ablauf zugeschnittene Anwendung den Alltag spürbar erleichtert, lässt sie sich bauen – und greift dabei auf denselben Datenbestand zu wie alle anderen. Es entsteht keine zweite Wahrheit, sondern eine zweite Sicht.

Wie eine eigene Anwendung mit projectfacts zusammenspielt

Zwischen der selbstgebauten Anwendung und projectfacts liegt genau eine Schicht: die Schnittstelle. Was darüber läuft, entscheidet der Zugang, mit dem sich die Anwendung anmeldet.

Anmeldung über ein Gerätepasswort

Für eine Anbindung erzeugt sich ein Benutzer in projectfacts ein eigenes Gerätepasswort. Damit meldet sich die Anwendung an, nicht mit dem persönlichen Kennwort. Der Vorteil zeigt sich beim Aufräumen: Ein Gerätepasswort lässt sich einzeln zurückziehen, ohne dass jemand sein Kennwort ändern oder seine Zwei-Faktor-Anmeldung neu einrichten muss.

Rechte kommen aus projectfacts

Die Anwendung sieht, was der Benutzer sehen darf, hinter dem der Zugang hängt. Wer in projectfacts keine Personaldaten öffnen kann, bekommt sie auch über die Schnittstelle nicht. Für eine Anbindung empfiehlt sich deshalb ein eigener Zugang mit genau den Rechten, die sie braucht – ein Werkzeug, das Zeiten bucht, braucht keinen Zugriff auf Löhne.

Lesen und schreiben

Die Schnittstelle arbeitet in beide Richtungen. Eine Anwendung kann Projekte und Aufgaben abrufen und ebenso Datensätze anlegen, etwa einen Zeiteintrag, einen Kontakt oder einen Beleg. Damit ist eine eigene Oberfläche nicht auf Anzeigen beschränkt, sondern kann Arbeit tatsächlich abnehmen.

Wenn projectfacts von sich aus meldet

Umgekehrt kann projectfacts eine Adresse bei Ihnen aufrufen, sobald etwas passiert ist – über einen Webhook. Das erspart der eigenen Anwendung das ständige Nachfragen. Und wenn die Fragen jedes Mal andere sind und gar keine Anwendung entstehen soll, ist der MCP-Server der kürzere Weg: Dann stellt ein KI-Assistent die Frage direkt.

Eigene Anwendungen greifen über die Schnittstelle von projectfacts auf Projekte, Zeiten und Belege zu | projectfacts

In vier Schritten zur ersten eigenen Anwendung

Der Weg ist kürzer, als er klingt – vorausgesetzt, das Modell bekommt die richtige Grundlage.

1. Zugang anlegen

Einen Benutzer mit den nötigen Rechten anlegen und dafür ein Gerätepasswort erzeugen, in projectfacts unter „Persönliche Einstellungen → Geräte → Neues Gerätepasswort“. Damit meldet sich die Anwendung später an.

2. Dem Modell die Beschreibung geben

Ab Version 26.2 liefert jeder projectfacts-Server eine maschinenlesbare OpenAPI-Beschreibung der Schnittstelle, unter der eigenen Server-Adresse gefolgt von /api/openapi.json. Dazu kommen die frei zugänglichen Anleitungen im Hilfecenter. Wer beides dem Modell als Quelle nennt, bekommt Code, der zu den tatsächlichen Adressen und Feldern passt – statt zu erfundenen.

3. Das Vorhaben beschreiben

Nicht die Technik beschreiben, sondern den Ablauf: wer die Anwendung benutzt, was er sieht, was er tippt, was danach passiert. Je genauer der Ablauf, desto weniger rät das Modell.

4. Ergebnis prüfen und übergeben

Ausprobieren, mit einem Testmandanten arbeiten, erst dann produktiv nehmen. Was bleibt, gehört ins normale Vorgehen Ihrer IT – mit eigenem Zugang, geprüft und von jemandem verantwortet.

Drei Beispiel-Prompts zum Kopieren

Jeder Prompt nennt zuerst die Beschreibung im Hilfecenter als Quelle, damit das Modell nicht raten muss, und legt fest, worauf es bei der Sicherheit ankommt: nur verschlüsselte Verbindungen, keine Zugangsdaten im Code, Daten vom Server als Text. Von Beispiel zu Beispiel wird die Anwendung größer.

Für Werkzeuge wie Claude Code, Cursor oder Codex. Ersetzen Sie vor dem Einfügen <Server-Adresse> durch die Adresse, unter der Sie projectfacts im Browser öffnen.

Mobile Zeiterfassung

Eine einzelne HTML-Datei, die bucht: Tage durchblättern mit den schon gebuchten Zeiten, Projekt wählen, Zeit starten und stoppen.

Meine projectfacts-Installation hat die Server-Adresse <Server-Adresse> (die Adresse, unter der ich projectfacts im Browser öffne). Baue eine Web-Anwendung als einzelne HTML-Datei ohne externe Abhängigkeiten zur mobilen Zeiterfassung, die sich über die REST-API mit projectfacts verbindet. Grundlage sind die OpenAPI-Beschreibung des Servers unter <Server-Adresse>/api/openapi.json (ab Version 26.2) und die Beschreibung der Schnittstelle im Hilfecenter unter help.teamspace.de (Thema API) – lies beides zuerst und halte dich an die dort beschriebenen Adressen, Felder und die Anmeldung per Gerätepasswort. Verwende als Adresse immer die Server-Adresse, die der Benutzer eingibt, nicht die Angabe unter „servers“ in der OpenAPI-Beschreibung. Angemeldet wird mit Server-Adresse, Geräte-ID und Token; das Gerätepasswort erzeugt der Benutzer in projectfacts unter „Persönliche Einstellungen → Geräte → Neues Gerätepasswort“.

Nach der Anmeldung sieht der Benutzer den heutigen Tag: oben die Zeiten, die er an diesem Tag schon gebucht hat (Projekt, Beginn und Ende, soweit vorhanden, Dauer und Beschreibung), mit der Tagessumme, darunter seine Projekte. Mit „zurück“ und „vor“ blättert er tageweise durch die Kalendertage und sieht jeweils die Buchungen dieses Tages; ein Sprung zurück auf heute ist jederzeit möglich. Für heute wählt er ein Projekt aus, startet die Zeiterfassung und beendet sie wieder. Der Zeiteintrag wird in projectfacts angelegt und erscheint danach sofort in der Tagesliste; Pflichtfelder der Buchung sind sichtbar und wählbar, nichts wird unbemerkt vorbelegt. Halte die Oberfläche auf einem Handy bedienbar und komme mit möglichst wenigen Bedienschritten aus.

Anforderungen: nur https-Adressen zulassen; Zugangsdaten nie im Code und nur dann dauerhaft speichern, wenn der Benutzer „Angemeldet bleiben“ wählt; Daten vom Server immer als Text ausgeben, nie als HTML. Texte auf Deutsch, Anrede Sie. Frage nach, bevor du etwas annimmst, das nicht in der Beschreibung steht.

Offene Punkte auf dem Handy

Eine einzelne HTML-Datei: die eigenen offenen Punkte nach Fälligkeit, die sich als erledigt markieren lassen.

Meine projectfacts-Installation hat die Server-Adresse <Server-Adresse> (die Adresse, unter der ich projectfacts im Browser öffne). Baue eine Web-Anwendung als einzelne HTML-Datei ohne externe Abhängigkeiten, die einem Mitarbeiter seine offenen Punkte aus projectfacts auf dem Handy zeigt. Gemeint ist das Modul „Offene Punkte“, in der Schnittstelle die Collection issue – keine Tickets. Grundlage sind die OpenAPI-Beschreibung des Servers unter <Server-Adresse>/api/openapi.json (ab Version 26.2) und die Beschreibung der REST-API im Hilfecenter unter help.teamspace.de (Thema API) – lies beides zuerst und halte dich an die dort beschriebenen Adressen, Felder und die Anmeldung per Gerätepasswort. Verwende als Adresse immer die Server-Adresse, die der Benutzer eingibt, nicht die Angabe unter „servers“ in der OpenAPI-Beschreibung. Angemeldet wird mit Server-Adresse, Geräte-ID und Token; das Gerätepasswort erzeugt der Benutzer in projectfacts unter „Persönliche Einstellungen → Geräte → Neues Gerätepasswort“.

Nach der Anmeldung sieht der Benutzer in einer Liste die offenen Punkte, die ihm zugewiesen sind, sortiert nach Fälligkeit; Überfälliges steht oben und ist hervorgehoben. Ein Tipp auf einen Eintrag zeigt Betreff, Projekt, Fälligkeit und Beschreibung. Offene Punkte lassen sich dort als erledigt markieren – frage vorher nach, ob das gewünscht ist, und aktualisiere danach die Liste. Die Rechte des Benutzers gelten unverändert: zeige nur, was der Server liefert.

Anforderungen: nur https-Adressen zulassen; Zugangsdaten nie im Code und nur dann dauerhaft speichern, wenn der Benutzer „Angemeldet bleiben“ wählt; Daten vom Server immer als Text ausgeben, nie als HTML; Fehlermeldungen des Servers verständlich anzeigen. Texte auf Deutsch, Anrede Sie. Frage nach, bevor du etwas annimmst, das nicht in der Beschreibung steht.

Cockpit für die Projektleitung

Eine React-Anwendung mit mehreren Ansichten, die nur liest: Projekte mit Budget-Ampel, Detailansicht mit Stunden und offenen Punkten.

Meine projectfacts-Installation hat die Server-Adresse <Server-Adresse> (die Adresse, unter der ich projectfacts im Browser öffne). Baue mit React, TypeScript und Vite eine Web-Anwendung für Projektleiter, die sich über die REST-API mit projectfacts verbindet. Grundlage sind die OpenAPI-Beschreibung des Servers unter <Server-Adresse>/api/openapi.json (ab Version 26.2) und die Beschreibung der Schnittstelle im Hilfecenter unter help.teamspace.de (Thema API) – lies beides zuerst und halte dich an die dort beschriebenen Adressen, Felder und die Anmeldung per Gerätepasswort. Verwende als Adresse immer die Server-Adresse, die der Benutzer eingibt, nicht die Angabe unter „servers“ in der OpenAPI-Beschreibung. Angemeldet wird mit Server-Adresse, Geräte-ID und Token; das Gerätepasswort erzeugt der Benutzer in projectfacts unter „Persönliche Einstellungen → Geräte → Neues Gerätepasswort“. Die Anwendung liest nur, sie ändert nichts in projectfacts.

Aufbau: 1. Übersicht der Projekte, die der angemeldete Benutzer leitet: Status, Budget, bisher gebuchter Aufwand und eine Ampel – grün unter 80 Prozent des Budgets, gelb bis 100 Prozent, rot darüber. Filter nach Status und Kunde, Suche nach Name. 2. Detailansicht je Projekt: Budget gegen Ist als Balken, gebuchte Stunden je Mitarbeiter und je Woche für die letzten zwölf Wochen, offene Punkte (Collection issue) und Tickets sowie der Rechnungsstatus, soweit die Schnittstelle diese Angaben liefert. 3. Jede Ansicht hat eine eigene Adresse über den Teil nach # und lässt sich als Link weitergeben.

Technische Vorgaben: keine Abhängigkeiten außer React, React DOM und Vite; Diagramme als einfaches SVG selbst gezeichnet, keine Diagramm-, Router- oder UI-Bibliothek. Der Build erzeugt statische Dateien mit relativem Basispfad, die in einem Unterverzeichnis ohne Server-Logik laufen; alle Dateien lokal, nichts von einem CDN. API-Zugriffe in einem eigenen Modul bündeln, Antworten typisieren, Anfragen parallel stellen, wo es geht, Ladezustand und Fehler je Ansicht anzeigen. Nur https-Adressen zulassen; Zugangsdaten nie im Code und nur mit „Angemeldet bleiben“ dauerhaft speichern; Serverdaten immer als Text ausgeben, nie als HTML. Texte auf Deutsch, Anrede Sie; auf Desktop und Tablet gut lesbar, auf dem Handy bedienbar.

Wenn eine Angabe – etwa Projektleitung, Budget oder Rechnungsstatus – nicht aus der Beschreibung hervorgeht, frage nach, statt sie zu erfinden.

Vier Anwendungen, die sich auf diese Weise bauen lassen

Die folgenden Beispiele sind keine fertigen Produkte, sondern Zuschnitte, nach denen in der Praxis am häufigsten gefragt wird.

Mobile Zeiterfassung

Anmelden, Projekt wählen, Zeit starten und stoppen. Der Eintrag landet in der Arbeitszeiterfassung und damit im selben Bestand wie jede andere Buchung.

Offene Punkte auf dem Handy

Eigene Aufgaben und Tickets in einer reduzierten Ansicht, direkt abhakbar. Die Daten kommen aus dem Aufgabenmanagement und dem Ticketsystem.

Übersicht für die Projektleitung

Status, Budget, gebuchte Zeiten und offene Punkte auf einem Schirm zusammengeführt – die Zahlen dafür liefert das Projektcontrolling.

Eigenes Portal für Kunden

Projektstand, Dokumente, Tickets und Rechnungen in einer eigenen Oberfläche. Wer keine eigene bauen möchte: projectfacts bringt dafür bereits ein Kundenportal mit.

Was Sie dabei im Blick behalten sollten

Software, die im Dialog mit einer KI entstanden ist, ist Software wie jede andere – mit denselben Pflichten.

Prüfen bleibt Ihre Aufgabe

Code, den niemand gelesen hat, kann funktionieren und trotzdem falsch sein. Bevor eine Anwendung produktiv geht, gehört sie geprüft – am besten von jemandem, der sie im Zweifel auch anpassen kann.

Ein eigener Zugang je Anwendung

Nicht der Zugang des Geschäftsführers für alles. Ein eigener Benutzer mit möglichst wenigen Rechten und einem eigenen Gerätepasswort macht später den Unterschied, wenn etwas zurückgezogen werden muss.

Was schnell entsteht, muss lange laufen

Eine Anwendung, die in einem Nachmittag entstanden ist, wird in zwei Jahren immer noch benutzt. Wer schon beim Bauen festlegt, wer sie verantwortet, spart sich die unangenehme Frage später.

Sie möchten eine eigene Anwendung an projectfacts anbinden?

In einer kostenlosen Erstberatung schauen wir uns an, welche Daten fließen sollen, welcher Zugang dafür der richtige ist und ob die Schnittstelle, ein Webhook oder der MCP-Server der kürzere Weg ist.

Jetzt Beratung anfragen

Noch Fragen? Wir haben die passende Antwort!

Sie möchten die Beschreibung der Schnittstelle einsehen oder ein konkretes Vorhaben besprechen? Sprechen Sie uns an.

Zum Kontakt Zur REST-API Zum Hilfecenter

Häufige Fragen zu Vibe Coding mit projectfacts

Kann ich mit projectfacts eigene Oberflächen entwickeln?

Ja. Über die REST-API greift eine selbstgebaute Anwendung auf dieselben Daten zu, mit denen Ihre Mitarbeiter in der Oberfläche arbeiten – lesend und schreibend. Damit lassen sich eigene Ansichten und Apps bauen, die auf einen bestimmten Ablauf zugeschnitten sind.

Kann ich projectfacts als Backend für eigene Apps verwenden?

Ja. Kundenverwaltung, Projekte, Aufgaben, Zeiten, Tickets und Abrechnung bleiben in projectfacts, die eigene Anwendung holt sich über die Schnittstelle genau das, was sie braucht. Sie müssen diese Funktionen also nicht nachbauen, sondern nur die Oberfläche für Ihren Fall.

Kann ich mit Werkzeugen wie Claude Code, Cursor oder Codex Anwendungen für projectfacts entwickeln?

Ja. Solche Werkzeuge schreiben Code für jede Schnittstelle, deren Aufbau sie kennen. Nennen Sie dem Modell die OpenAPI-Beschreibung Ihres Servers (ab Version 26.2 unter /api/openapi.json) und die Anleitungen im Hilfecenter als Quelle – dort stehen der Aufbau der Adressen, die Anmeldung und die Felder. Auf dieser Seite finden Sie drei Beispiel-Prompts zum Kopieren, von einer einzelnen HTML-Datei bis zu einer React-Anwendung.

Wie meldet sich eine selbstgebaute Anwendung an?

Über ein Gerätepasswort, das sich ein Benutzer in projectfacts unter „Persönliche Einstellungen → Geräte → Neues Gerätepasswort“ erzeugt, nicht über das persönliche Kennwort. Ein solches Gerätepasswort lässt sich einzeln zurückziehen. Für Zugänge, die zu keiner Person gehören, etwa an einem Terminal, gibt es zusätzlich neutrale Zugangsberechtigungen.

Gelten die Berechtigungen auch in der eigenen Anwendung?

Ja, und das ist der wichtigste Punkt. Über die Schnittstelle – und damit auch in der eigenen Anwendung – hat jemand genau die Rechte, die er in projectfacts hätte. Die Schnittstelle kennt kein eigenes Rechtesystem und öffnet keine zusätzlichen Türen.

Kann eine Web-App direkt aus dem Browser auf die Schnittstelle zugreifen?

Ja, ein direkter Zugriff aus einer Webanwendung ist möglich. Achten Sie dabei darauf, wo die Zugangsdaten liegen: Ein Gerätepasswort, das offen im Browser steht, kann jeder auslesen, der die Anwendung öffnet. Für Anwendungen, die mehrere Personen nutzen, ist ein eigener kleiner Dienst dazwischen der sauberere Weg.

Muss ich für die Schnittstelle etwas dazubuchen?

Die Schnittstelle gehört zum Funktionsumfang von projectfacts. Welche Funktionen in welcher Produktvariante enthalten sind, zeigt die vollständige Funktionsübersicht.

Ist so entstandene Software für den produktiven Einsatz geeignet?

Für kleine, klar abgegrenzte Werkzeuge häufig ja. Es gelten dabei aber dieselben Anforderungen wie bei jeder anderen Software: Der Code sollte geprüft sein, die Anwendung einen eigenen Zugang mit wenigen Rechten haben, und jemand sollte sie verantworten. Wer das überspringt, verlagert den Aufwand nur nach hinten.