KULIMO — Leistungen
Web-App-Entwicklung Berlin: gebaut, um mit Ihnen zu wachsen
Eine Web-App ist Software, die direkt im Browser läuft — ohne Installation, auf jedem Gerät, für Ihr Team und Ihre Kunden sofort nutzbar. KULIMO entwickelt Web-Apps und Progressive Web Apps mit skalierbarer Architektur: technisch durchdacht, flexibel erweiterbar und so gebaut, dass Ihre digitale Infrastruktur niemals zum Engpass wird — nicht bei zehn Nutzern, nicht bei zehntausend.
Erstgespräch vereinbaren
- Django
- React
- PWA
- Swift
- Flutter
- Offline-fähig
- Kein Vendor-Lock-in
- DSGVO-konformes Hosting
Web-App-Entwicklung Berlin: das Wichtigste im Überblick
Diese Seite zeigt, wann eine Web-App die richtige Lösung ist, was sie kostet, wo Ihre Daten liegen und woran Sie erkennen, ob die Anwendung im Alltag trägt.
Wann eine Web-App passt
Die ehrliche Abgrenzung zu Website, Standardsoftware und nativer App.
Was skalierbar bedeutet
Mehr Nutzer, mehr Daten, neue Funktionen — ohne Neubau.
Web-App, PWA oder nativ
Drei Bauformen und ihre jeweiligen Einsatzgebiete.
Daten und Hosting
Wo eine Web-App läuft und wem die Daten gehören.
Kosten
Woran sich der Aufwand tatsächlich festmacht.
Betrieb und Kennzahlen
Was nach dem Start zählt — und wie wir es messen.
Wann eine Web-App die richtige Lösung ist
Nicht jedes Problem braucht eine App — und nicht jede App muss nativ sein. Die ehrliche Einordnung:
| Ihre Situation | Website | Web-App | Native App | Standardsoftware |
|---|---|---|---|---|
| Sie wollen gefunden werden und informieren | ✓ | |||
| Ihr Team arbeitet mit Excel-Listen, die drei Leute parallel pflegen | ✓ | |||
| Kunden sollen buchen, bestellen oder Vorgänge einsehen | ✓ | |||
| Ihre Abläufe passen in keine Standardsoftware — oder nur mit Verrenkungen | ✓ | |||
| Sie brauchen Kamera, Push oder App-Store-Präsenz als Kern der Lösung | ✓ | |||
| Ein Standard-Tool deckt 95 % Ihres Bedarfs ab | ✓ |
Der letzte Fall ist uns wichtig: Wenn eine bewährte Standardlösung Ihr Problem löst, sagen wir Ihnen das. Individualentwicklung lohnt sich dort, wo Ihre Abläufe Ihr Wettbewerbsvorteil sind — nicht dort, wo ein fertiges Werkzeug für einen Bruchteil dasselbe kann.
Was „skalierbar“ wirklich bedeutet — und was nicht
„Skalierbar“ ist das meistmissbrauchte Wort der Branche. Bei uns bedeutet es vier konkrete Dinge:
Mehr Nutzer, gleiche Geschwindigkeit
Die Anwendung bleibt schnell, wenn aus fünf Mitarbeitenden fünfzig werden — durch effiziente Datenbankstrukturen und eine Architektur, die Last verteilt statt sie zu stapeln.
Mehr Daten, weiter durchsuchbar
Zehntausende Vorgänge, Dokumente oder Fahrzeuge dürfen die Anwendung nicht in die Knie zwingen. Das entscheidet sich am Datenmodell — am Anfang, nicht am Ende.
Neue Funktionen ohne Neubau
Modulare Struktur statt verwachsenem Monolithen: Ein neues Modul andocken, ohne dass drei alte brechen.
Kein Vendor-Lock-in
Ihre Daten, Ihre Anwendung, Ihre Exportwege. Sie sind nicht an eine Plattform gekettet, deren Preise steigen, sobald der Wechsel wehtut.
Und genauso wichtig ist die Gegenrichtung: Skalierbarkeit heißt nicht, für Millionen Nutzer zu bauen, die Sie nicht haben. Über-Architektur kostet Geld und Tempo. Wir bauen für Ihre realistische Wachstumskurve — mit sauberen Erweiterungspunkten für den Tag, an dem mehr nötig ist.
Die Engpässe, die wir verhindern
Digitale Infrastruktur wird selten mit einem Knall zum Problem — sie wird es schleichend:
Das Lizenz-Modell wächst schneller als Sie.
Pro-Kopf-Preise externer Tools werden bei 5 Mitarbeitenden belächelt und bei 50 zum sechsstelligen Jahresposten.
Werkzeuge, die nicht miteinander reden.
Termine hier, Kunden dort, Rechnungen woanders — und dazwischen Copy-and-paste als Schnittstelle.
Software, die offline nicht funktioniert.
Auf Baustellen, in Tiefgaragen, beim Kunden vor Ort ist „braucht stabiles Internet“ ein Ausschlusskriterium.
Daten auf fremden Servern.
Wer Unternehmenskommunikation und Kundendaten auf US-Plattformen liegen hat, beantwortet die DSGVO-Frage jeden Tag neu.
Der eine Entwickler, der alles weiß.
Undokumentierte Systeme sind ein Personalrisiko, kein Asset.
Jede Web-App von KULIMO wird gegen diese fünf Engpässe gebaut: eigene Datenhoheit, offene Schnittstellen, Offline-Fähigkeit wo nötig, Dokumentation als Pflichtteil der Übergabe. Für die Automatisierung interner Abläufe siehe auch Individualsoftware.
Web-App, Progressive Web App oder native App?
Web-App
Läuft im Browser, ein Codestand für alle Geräte, Updates sofort für alle Nutzer. Die richtige Wahl für interne Werkzeuge, Verwaltungs- und Kundenportale.
Progressive Web App (PWA)
Eine Web-App mit Superkräften: auf dem Startbildschirm installierbar, offlinefähig, schnell wie eine native App — ohne App-Store-Umweg. Die richtige Wahl, wenn Mobilität und Offline-Betrieb zählen, etwa auf der Baustelle.
Native App (iOS/Android)
Maximaler Zugriff auf Gerätefunktionen wie Kamera-Pipelines oder Push. Die richtige Wahl, wenn die App selbst das Produkt ist — wie bei unserer KI-Fahrzeugfotografie für iOS.
Welche Variante passt, ist keine Glaubensfrage, sondern eine Anforderungsfrage — und oft ist die Antwort eine Kombination: Web-App fürs Büro, PWA fürs Feld.
Technologie: bewährt statt modisch
Wir entwickeln mit einem bewährten, breit getragenen Stack — unter anderem Django und React für Web-Apps, Swift für iOS und Flutter, wo plattformübergreifende mobile Apps gefragt sind. Die Auswahl folgt dabei immer derselben Regel: Die Technologie dient dem Problem, nicht dem Lebenslauf des Entwicklers.
Das heißt konkret: etablierte Frameworks mit großer Community statt Nischen-Experimenten, saubere Trennung von Daten, Logik und Oberfläche, automatisierte Tests für die kritischen Pfade — und eine Dokumentation, mit der auch ein fremdes Team die Anwendung übernehmen könnte. Dass sie das nie muss, ist unser Ziel. Dass sie es könnte, ist Ihre Sicherheit.
Aus der Praxis: Anwendungen, die heute im Einsatz sind
Bauprojekt-Management — offlinefähig auf der Baustelle
Baudokumentation, Lagerverwaltung und Protokolle, mobil auf jedem Gerät — und als PWA auch dort nutzbar, wo kein Netz ist. Synchronisiert, sobald die Verbindung zurückkommt.
Zur Anwendung →Autohaus-CRM — ein System statt Zettelwirtschaft
Fahrzeugbestand, Kundendaten, Verkaufsprozesse und Teamaufgaben in einer Web-App, in Echtzeit, im Browser. Gebaut für den Alltag im Handel, nicht für die Konzern-IT.
Zur Anwendung →Self-hosted Kommunikation — Ihre Daten auf Ihrem Server
Team-Kommunikation ohne US-Cloud: Die Anwendung läuft auf Ihrer eigenen Infrastruktur, und die Frage „Wer hat Zugriff?“ hat genau eine Antwort — Sie.
Zur Anwendung →Alle Projekte: Anwendungen ansehen →
Der Weg zur eigenen Web-App
Prozess-Analyse
Wir schauen auf Ihren echten Ablauf — nicht auf ein Wunschbild. Wo entsteht Handarbeit, wo Doppelerfassung, wo Wartezeit?Ergebnis: die Engpass-Liste mit Priorisierung.
MVP-Zuschnitt
Welcher kleinste Funktionsumfang löst das größte Problem? Wir starten fokussiert statt mit einem Zwei-Jahres-Pflichtenheft.Ergebnis: ein klar umrissener erster Ausbau.
Design & Prototyp
Oberflächen für die Menschen, die täglich damit arbeiten — inklusive der Sonderfälle, Fehlermeldungen und Barrierefreiheit.Ergebnis: ein klickbarer Prototyp vor der ersten Zeile Produktionscode.
Entwicklung in Etappen
Kurze Zyklen, testbare Zwischenstände, Ihr Feedback fließt laufend ein.Ergebnis: eine Anwendung, die beim Go-live schon vom Team validiert ist.
Betrieb & Ausbau
Hosting, Sicherheit, Updates — und die Weiterentwicklung entlang dessen, was der Betrieb zeigt.Ergebnis: Software, die mitwächst, statt zu veralten.
Wo Ihre Web-App läuft — und wem die Daten gehören
Bei interner Software ist die Standortfrage keine Formalie. Sie entscheidet darüber, wer Zugriff hat, wie geprüft wird und was passiert, wenn ein Anbieter seine Bedingungen ändert.
Hosting in Deutschland oder auf Ihrer Infrastruktur
Eine Web-App muss nicht bei einem US-Anbieter liegen. Wir betreiben Anwendungen in deutschen Rechenzentren oder direkt auf Ihren Servern — je nachdem, was Ihre Branche verlangt.
Datenschutz als Bauentscheidung
Welche Daten erhoben werden, wie lange sie bleiben und wer sie sieht, gehört in die Konzeption. Die gesetzliche Grundlage dafür bildet neben der DSGVO das Bundesdatenschutzgesetz.
Rollen und Zugriffe
Nicht jede Person braucht jede Ansicht. Eine sauber geschnittene Rechteverwaltung ist der einfachste Schutz vor versehentlichen Datenabflüssen — und in jeder Web-App von Anfang an vorgesehen.
Sicherheit nach anerkannten Standards
Verschlüsselte Übertragung, getrennte Umgebungen, regelmäßige Aktualisierung. Als Orientierung dienen die Empfehlungen des BSI.
Bestehende Systeme anbinden statt ersetzen
Die wenigsten Unternehmen starten auf der grünen Wiese. Buchhaltung, Warenwirtschaft und Kalender sind da — und funktionieren. Die Aufgabe ist selten Ablösung, sondern Verbindung.
Dokumentierte Schnittstellen
Moderne Systeme bringen eine API mit. Dann ist die Anbindung eine Frage von Tagen: Daten werden ausgetauscht, ohne dass jemand etwas doppelt eintippt.
Ältere Software ohne API
Auch dafür gibt es Wege — geplante Exporte, Dateiablagen, Datenbankzugriff mit Lesekonto. Weniger elegant, aber verlässlich und deutlich günstiger als eine Ablösung.
Eine Richtung zuerst
Wir beginnen fast immer mit einem einseitigen Abgleich: Daten fließen in eine Richtung, bis sich der Ablauf gesetzt hat. Beidseitige Synchronisation kommt danach, wenn sie überhaupt nötig ist.
Klare Zuständigkeit für Datenstände
Für jedes Feld wird festgelegt, welches System die Wahrheit hält. Diese eine Festlegung verhindert die meisten Konflikte, bevor sie entstehen.
Was eine Web-App kostet — und woran Sie das Budget festmachen
Pauschalpreise wären unseriös. Aber es gibt vier Faktoren, an denen sich der Aufwand zuverlässig ablesen lässt.
Zahl der Abläufe
Ein einzelner Vorgang mit Übersicht und Detailansicht ist überschaubar. Sobald Angebot, Auftrag, Rechnung und Nachbetreuung in einer Web-App zusammenlaufen, wächst der Umfang entsprechend.
Anzahl der Rollen
Ein Team mit gleichen Rechten ist schnell abgebildet. Unterschiedliche Sichten für Innendienst, Außendienst und Leitung bedeuten mehr Logik und mehr Tests.
Schnittstellen
Jede Anbindung an Buchhaltung, Warenwirtschaft oder Kalender ist ein eigenes kleines Projekt — abhängig davon, wie gut die Gegenstelle dokumentiert ist.
Offlinefähigkeit
Eine Web-App, die ohne Netz weiterarbeiten und später synchronisieren muss, braucht zusätzliche Architektur. Auf der Baustelle ist das entscheidend, im Büro selten nötig.
Wir schneiden Projekte deshalb auf einen kleinsten wirksamen Umfang zu: den einen Ablauf, der am meisten Zeit frisst. Diese erste Ausbaustufe ist meist in wenigen Wochen im Einsatz und finanziert die nächste aus der eingesparten Arbeitszeit.
Fünf Fehler, die Web-App-Projekte teuer machen
Diese Muster kosten in der Praxis mehr Geld als jede technische Entscheidung.
Das Pflichtenheft für alles
Wer zwei Jahre plant, baut an der Realität vorbei. Bis zur Fertigstellung hat sich der Prozess geändert. Eine Web-App entsteht besser in Etappen, die einzeln nutzbar sind.
Ohne die späteren Nutzer planen
Wenn nur die Leitung den Ablauf beschreibt, fehlen genau die Ausnahmen, die den Alltag ausmachen. Die beste Web-App scheitert an einem Sonderfall, den niemand erwähnt hat.
Alles selbst bauen wollen
Zahlungsabwicklung, Kartendienste, Dokumentenerzeugung: Für vieles gibt es bewährte Bausteine. Eigenentwicklung lohnt dort, wo Ihr Ablauf besonders ist — nicht beim Standard.
Migration erst am Schluss
Alte Daten sind selten sauber. Wer die Übernahme ans Ende schiebt, verschiebt den Start. Wir prüfen Bestandsdaten, sobald der Datenschnitt der Web-App steht.
Kein Budget für den Betrieb
Software altert. Ohne Aufwand für Updates, Sicherheit und kleine Anpassungen wird aus der neuen Anwendung in drei Jahren dasselbe Problem, das Sie heute lösen wollen.
Einführung im Team: wie neue Software angenommen wird
Technisch fertig heißt nicht angekommen. Die Einführung entscheidet darüber, ob ein Werkzeug benutzt oder umgangen wird.
Früh mitbauen lassen
Wer den Prototyp schon gesehen und kommentiert hat, wartet später nicht auf eine Schulung, sondern kennt die Oberfläche bereits. Beteiligung ersetzt Überzeugungsarbeit.
Mit einem Bereich starten
Ein Team, ein Standort, ein Ablauf. Was dort funktioniert, überzeugt die übrigen Bereiche schneller als jede Präsentation — und Fehler bleiben klein.
Den alten Weg abschalten
Solange die Excel-Liste daneben weiterläuft, entstehen zwei Wahrheiten. Ein festes Datum für die Umstellung gehört deshalb zum Einführungsplan.
Wir begleiten die ersten Wochen aktiv: kurze Einweisung statt Handbuch, ein fester Ansprechpartner für Rückfragen und zwei bis drei kleine Anpassungen, die sich erst im echten Betrieb zeigen. Danach übernimmt Ihr Team — und wir bleiben für Wartung und Ausbau erreichbar.
Betrieb: woran Sie erkennen, dass die Web-App trägt
Nach dem Start zählt nicht die Funktionsliste, sondern was sich im Arbeitsalltag verändert. Vier Werte machen das sichtbar.
Bearbeitungszeit pro Vorgang
Die ehrlichste Zahl. Wenn ein Vorgang nach Einführung der Web-App messbar schneller durchläuft, hat sich das Projekt gerechnet.
Anteil mobiler Nutzung
Wird die Anwendung dort benutzt, wo gearbeitet wird? Als installierbare Progressive Web App läuft sie auch offline auf dem Tablet.
Zahl der Umgehungen
Entstehen weiterhin Excel-Listen neben dem System, fehlt eine Funktion. Diese Beobachtung ist die beste Grundlage für den nächsten Ausbau.
Zeit bis zur Änderung
Wie lange dauert eine neue Auswertung? Bei sauberer Architektur sind das Tage, nicht Quartale. Grundlagen dazu dokumentiert MDN Web Docs.
FAQ
Häufige Fragen zur Web-App-Entwicklung
Was ist der Unterschied zwischen einer Website und einer Web-App?
Eine Website informiert — eine Web-App arbeitet: Nutzer melden sich an, erfassen Daten, verwalten Vorgänge, lösen Prozesse aus. Technisch fließend, praktisch entscheidend: Die Web-App ersetzt Werkzeuge und Handarbeit, die Website ersetzt den Prospekt.
Muss mein Team etwas installieren?
Nein. Web-Apps laufen im Browser — auf jedem Gerät, sofort aktuell für alle. Als Progressive Web App lässt sich die Anwendung zusätzlich auf dem Startbildschirm ablegen und offline nutzen.
Funktioniert eine Web-App auch ohne Internet?
Als PWA: ja. Erfasste Daten werden lokal gespeichert und synchronisiert, sobald wieder Verbindung besteht — im Einsatz etwa bei unserer Bauprojekt-Anwendung für Baustellen ohne Netzabdeckung.
Wir nutzen bereits mehrere Tools. Können die angebunden werden?
In den meisten Fällen ja — über Schnittstellen zu Buchhaltung, Kalender, E-Mail, Zahlungsanbietern oder Warenwirtschaft. Welche Anbindungen sinnvoll und technisch sauber machbar sind, klären wir in der Prozess-Analyse.
Wem gehören Code und Daten?
Ihnen. Sie erhalten Datenhoheit, Exportwege und Dokumentation. Auf Wunsch läuft die Anwendung vollständig auf Ihrer eigenen Infrastruktur — wie bei unserer Self-hosted-Kommunikationslösung.
Was passiert, wenn wir wachsen — mehr Nutzer, mehr Daten, neue Standorte?
Genau dafür ist die Architektur gebaut: modulare Struktur, belastbares Datenmodell, Erweiterungspunkte für neue Module und Rollen. Wachstum ist der Normalfall, für den wir planen — nicht der Sonderfall, der alles sprengt.
Ist so eine Anwendung DSGVO-konform?
Datenschutz ist Teil der Architektur: Hosting in Deutschland oder auf Ihrer Infrastruktur, Rollen- und Rechtekonzepte, Löschkonzepte und dokumentierte Datenflüsse. Nicht als nachträgliches Häkchen, sondern von Anfang an.
Wovon hängen die Kosten ab?
Vom Funktionsumfang des ersten Ausbaus, der Zahl der Schnittstellen, den Anforderungen an Offline-Betrieb und Hosting sowie dem laufenden Betreuungsbedarf. Nach Prozess-Analyse und MVP-Zuschnitt erhalten Sie ein Festangebot ohne versteckte Positionen.
Wie lange dauert es bis zur ersten nutzbaren Version?
Für einen klar umrissenen Ablauf rechnen wir mit sechs bis zwölf Wochen bis zur ersten produktiv genutzten Ausbaustufe. Entscheidend ist nicht die Technik, sondern wie schnell im Unternehmen entschieden wird, welcher Prozess zuerst in die Web-App wandert.
Können wir später von der Web-App auf eine native App wechseln?
Ja. Wenn Datenmodell und Schnittstellen sauber getrennt sind, lässt sich später eine native Oberfläche ergänzen, ohne die Logik neu zu bauen. In den meisten Fällen reicht allerdings eine installierbare Progressive Web App vollständig aus.
Was passiert, wenn wir die Zusammenarbeit beenden?
Sie erhalten Code, Daten und Dokumentation vollständig und in nutzbarer Form. Die Web-App läuft auf Ihrer Infrastruktur weiter, und jedes andere Entwicklungsteam kann übernehmen. Es gibt keine Lizenz, die abläuft, und keinen Schlüssel, den wir behalten.
Können mehrere Standorte mit derselben Anwendung arbeiten?
Ja, das ist einer der Hauptgründe für eine Web-App: Sie läuft im Browser, es gibt nichts zu installieren, und alle Standorte sehen denselben Datenstand. Unterschiedliche Rechte, Sprachen oder Nummernkreise je Standort lassen sich abbilden, ohne die Anwendung zu duplizieren.
Wie sichern Sie Daten und was passiert bei einem Ausfall?
Automatische Sicherungen laufen täglich, zusätzlich vor jedem Update, und werden regelmäßig testweise zurückgespielt — eine Sicherung, die nie wiederhergestellt wurde, ist keine. Für den Ausfall eines Servers halten wir je nach Anforderung eine zweite Umgebung bereit, in die innerhalb kurzer Zeit umgeschaltet werden kann.
Arbeiten Sie auch an einer bestehenden Anwendung weiter?
Ja, wenn der Code lesbar und die Datenbank nachvollziehbar strukturiert ist. Wir beginnen dann mit einer Bestandsaufnahme: Wir sichten Architektur, Abhängigkeiten und offene Sicherheitsthemen und sagen ehrlich, ob Weiterentwicklung oder Neubau günstiger ist. In etwa der Hälfte der Fälle lohnt sich die Übernahme — vor allem, wenn fachliche Logik über Jahre gewachsen ist, die niemand ein zweites Mal formulieren möchte.
Wie viel Zeit muss unser Team einplanen?
Rechnen Sie in der Konzeptphase mit etwa einem halben Tag pro Woche für die Person, die den Prozess am besten kennt, und mit kürzeren Rückmeldeschleifen während der Entwicklung. Wichtiger als die Menge ist die Verlässlichkeit: Ein fester wöchentlicher Termin bringt ein Projekt schneller voran als sporadisch längere Sitzungen.
Wo ist Ihr Engpass?
Im Erstgespräch finden wir den einen Prozess, der Ihr Team heute am meisten Zeit kostet — und klären, ob eine Web-App ihn löst oder eine einfachere Lösung reicht. Unverbindlich, konkret, ohne Verkaufsdruck.
Erstgespräch vereinbaren