Leistung
Individuelle Webanwendungsentwicklung
Plattformen, die echter Last, echten Daten und echten Nutzern standhalten.
Im Web lebt das meiste von dem, was wir bauen: interne Plattformen, die ein Geschäft führen, Kundenportale, Dashboards über echten operativen Daten und öffentliche Seiten, die schnell und auffindbar sein müssen. Als Anwendungen gebaut statt aus Plugins zusammengesetzt, und genau das macht sie ein Jahr später noch änderbar.
Die Entscheidung
Wann das die richtige Wahl ist.
Die Entscheidung lautet selten individuell gegen nichts. Sie lautet individuell gegen eine Plattform plus die Plugins, die die Lücke zwischen deren Leistung und Ihrem Bedarf schließen. Dieser Stapel ist günstig im Start und teuer im Besitz: jedes Plugin ist eine Abhängigkeit, ein Performance-Kostenfaktor und eine Angriffsfläche, und die Kombination bricht beim nächsten großen Release der Plattform.
Die zweite Kostenstelle ist die Obergrenze. Plattformbasierte Projekte sind schnell, bis zur ersten Anforderung, die die Plattform nicht ausdrücken kann — und dann wird der Workaround zur Architektur. Unternehmen richten sich am Ende nach ihrer Software statt umgekehrt, also genau in der Lage, die zu vermeiden die Software gekauft wurde.
Individuell lohnt sich, wenn die Fachlogik das Produkt ist, wenn das Datenmodell wirklich Ihnen gehört, oder wenn Performance und Integration so sehr zählen, dass sie zu technischen Entscheidungen werden. Trifft nichts davon zu, sagen wir das — eine gut gewählte Plattform ist die bessere Antwort als ein Projekt, an dem wir mehr Freude hätten.
Was Sie bekommen
Was die Arbeit umfasst.
Eine Architektur, die Wachstum aushält
Datenmodell, Grenzen und Deployment werden vor dem ersten Bildschirm entschieden, denn das sind die Entscheidungen, deren Umkehr teuer ist.
Serverseitig gerendert, wo es zählt
Seiten, die Crawler und langsames Telefon gleichermaßen vollständig erhalten, mit Interaktivität obendrauf statt als Bedingung dafür, dass Inhalt erscheint.
Echte Autorisierung
Berechtigungen werden serverseitig bei jeder Anfrage durchgesetzt, nicht durch ausgeblendete Menüpunkte. Geprüft durch Tests, die sie zu brechen versuchen.
Performance als festes Budget
Core Web Vitals gelten als Build-Vorgabe mit einer Zahl, nicht als Bericht, der nach dem Launch läuft.
Barrierefreiheit von Anfang an
Tastaturwege, Fokusführung, Kontrast und Semantik ab der ersten Komponente, was günstiger ist als Nachrüsten und zugleich besser für die Suche.
Im Betrieb beherrschbar
Logging, Fehlerberichte, Backups und eine geprobte Wiederherstellung, denn Software, die sich nicht betreiben lässt, ist nicht fertig.
Stack
Womit wir es bauen.
Je Projekt gewählt. Nichts davon wird standardmäßig gesetzt, und das Team, das es pflegen wird, wiegt so schwer wie das Problem.
Frontend
TypeScript mit React oder serverseitig gerenderte Templates, je Projekt gewählt. Kein Framework wird standardmäßig gesetzt.
Backend
Python, Node oder .NET, ebenso nach dem Team gewählt, das es pflegen wird, wie nach dem Problem.
Daten
PostgreSQL oder MySQL, mit entworfenem statt generiertem Schema. Redis dort, wo Caching wirklich hilft.
Infrastruktur
Linux, nginx, containerisiert wo es seine Komplexität wert ist — in Ihrer Cloud oder unserer.
Lieferung
Versionskontrolle, automatisierte Tests und eine Deploy-Pipeline ab Tag eins, nicht erst wenn es wehtut.
Vergleich
Plattform-Build oder Individualentwicklung.
Der Vergleich, den man führen sollte, bevor man irgendetwas beauftragt. Bei einem großen Teil der Projekte gewinnt die linke Spalte, und wir sagen das auch.
| Aspekt | Plattform + Plugins | Individuelle Entwicklung |
|---|---|---|
| Zeit bis zu etwas Nutzbarem | Tage. Das ist ein echter Vorteil und oft der ausschlaggebende. | Wochen. Nur gerechtfertigt, wenn die Plattform nicht ausdrücken kann, was Sie brauchen. |
| Kostenstruktur | Niedrig und wiederkehrend: Lizenz, Wachstum pro Platz, Abo je Plugin, der Implementierungspartner | Hoch und einmalig, danach Hosting. Der Code gehört Ihnen, ohne Laufzeitlizenz. |
| Die Obergrenze | Erreicht bei der ersten Anforderung, die die Plattform nicht ausdrücken kann; dann wird der Workaround zur Architektur | Von Ihren eigenen Designentscheidungen bestimmt, nicht von fremder Roadmap |
| Abhängigkeitsfläche | Jedes Plugin ist Code, den Sie nicht geschrieben haben, mit eigenem Release-Zyklus, innerhalb Ihres Sicherheitsbereichs | Nur die Bibliotheken, die Sie gewählt, geprüft und gepinnt haben |
| Große Versionswechsel | Was bricht, ist die Plugin-Kombination, und sie bricht nach fremdem Zeitplan | Sie entscheiden wann, und die Tests sagen Ihnen, was sich bewegt hat |
| Performance und Core Web Vitals | Theme plus Plugin-Overhead, behandelt durch ein weiteres Caching-Plugin | Eine Build-Vorgabe mit einer konkreten Zahl, erzwungen in der Pipeline |
Wie es abläuft
Vom ersten Gespräch bis live.
Richtwerte für Arbeit dieser Art. Der Pilot ist nicht optional — nichts wird umgestellt, bevor die Nutzer sagen, dass es trägt.
- 1-2 Wochen
Discovery
Wir modellieren zuerst die Daten und die Rollen. Dort liegen die Kosten tatsächlich, und dort gehen plattformbasierte Projekte meist schief — nicht bei den Bildschirmen.
- 4-8 Wochen
Kernentwicklung
Der am stärksten genutzte Weg von Anfang bis Ende, mit Ihren echten Daten und einer Deploy-Pipeline ab der ersten Woche statt erst wenn es wehtut.
- 2-3 Wochen
Pilot
Ein Team nutzt es für echte Arbeit, während der alte Ablauf weiterläuft. Jede Lücke, auf die sie stoßen, wird behoben, bevor jemand anderes umgestellt wird.
- 1-2 Wochen
Launch und Übergabe
Restliche Nutzer, Monitoring und Backups mit geprobter Wiederherstellung, dazu die Dokumentation, die eine Übernahme durch andere erlaubt.
Nach dem Launch
Was sich ändert.
- Die Anforderung, die die Plattform nicht ausdrücken konnte, wird nicht mehr von einem Menschen in einer Tabelle erledigt.
- Seitenperformance wird zu einer Zahl, die Sie halten, statt zu einem Plugin, von dem Sie hoffen, dass es wirkt.
- Upgrades sind kein Ereignis mehr, weil es keine Plugin-Kombination gibt, die brechen könnte.
- Eine Änderung in Woche sechzig kostet ungefähr so viel wie dieselbe Änderung in Woche sechs.
Bewusst qualitativ beschrieben. Wir veröffentlichen keine Prozentangaben, die wir nicht einem namentlich genannten Kunden mit dessen Zustimmung zuordnen können.
Fragen
Häufige Fragen.
Wie lange dauert eine individuelle Webanwendung?
Eine fokussierte interne Plattform braucht vom ersten Gespräch bis in den Betrieb meist acht bis vierzehn Wochen. Größere, mehrmodulige Systeme dauern länger und werden in Stufen geliefert, das erste Modul läuft bereits, während das nächste entsteht — uns ist lieber, Sie nutzen früh etwas Echtes, als auf alles zu warten.
Gehört uns der Code?
Ja, vollständig, einschließlich Repository und Deployment-Konfiguration. Es gibt keine Laufzeitlizenz und nichts, was eine Übernahme durch andere verhindert.
Können Sie mit unserem bestehenden System arbeiten?
In der Regel ja. Die meisten Projekte beginnen mit der Anbindung an etwas Vorhandenes — eine Buchhaltungssoftware, ein ERP, eine Altdatenbank. Alles auf einmal zu ersetzen ist selten richtig; ein stufenweiser Weg ist sicherer.
Was passiert nach dem Launch?
Ein Supportzeitraum ist enthalten; danach nehmen die meisten Kunden ein Retainer für Änderungen und Monitoring. Beides bindet Sie nicht: Der Code gehört Ihnen und ist gut genug dokumentiert, dass ihn jemand anderes übernehmen kann.
Sollten wir nicht einfach eine Plattform nehmen?
Oft ja. Passt Ihr Datenmodell zur Plattform und ist die Software nicht Ihr Unterscheidungsmerkmal, ist die Plattform schneller und günstiger, und wir sagen Ihnen das. Individuell verdient seine Kosten, wenn die Fachlogik das Produkt ist, wenn das Datenmodell wirklich Ihnen gehört, oder wenn Integration und Performance technische Probleme sind statt Einstellungen.
Was passiert, wenn sich unsere Anforderungen mitten im Projekt ändern?
Das werden sie, und der Plan geht davon aus. An jeder Phasengrenze wird mit dem neu Gelernten neu geschätzt, weshalb wir einen gedeckelten Preis je Phase einem Festpreis für den Gesamtumfang vorziehen — letzterer ist entweder für Risiko aufgeschlagen oder steuert beim ersten Wandel auf einen Streit zu.