Oberfläche
Schnell, zugänglich und auf Desktop, Smartphone sowie Tablet sinnvoll bedienbar.
Technologie, die zur Aufgabe passt – nicht umgekehrt
Kunden müssen keine Frameworks auswählen. Unsere Aufgabe ist, eine technische Grundlage zu wählen, die schnell, sicher, gut betreibbar und für den geplanten Lebenszyklus angemessen ist.
Technische Ausgangslage besprechen
KI · ERSTELLT
Vier Schichten. Eine verantwortete Lösung.
Technische Entscheidungen werden nicht isoliert getroffen.
Anwendungslogik
Geschäftsregeln, Rollen und Abläufe nachvollziehbar und erweiterbar abbilden.
Daten & Systeme
Datenmodelle, Dokumente und vorhandene Anwendungen kontrolliert verbinden.
Betrieb
Auslieferung, Monitoring, Backups und Wiederherstellung passend zum Risiko planen.
Warum moderne Webtechnologie?
Eine gemeinsame Basis für Website, Portal und Anwendung
React und Next.js ermöglichen schnelle, suchmaschinenfreundliche Oberflächen und interaktive Anwendungen innerhalb derselben Architektur.
Node.js eignet sich für serverseitige Funktionen, Datenverarbeitung und Integrationen. Wo andere Werkzeuge besser passen, werden sie gezielt ergänzt.
Was diese technische Grundlage für Sie konkret bedeutet.
Frameworks sind für den Betrieb nur dann wertvoll, wenn daraus eine schnelle, verlässliche und später veränderbare Lösung entsteht. Wir übersetzen die Technik deshalb in überprüfbare Eigenschaften.
Website und Anwendung können zusammenwachsen
Ein zunächst öffentlicher Webauftritt kann später um Login, Kundenbereich, Formulare oder individuelle Prozessfunktionen ergänzt werden, ohne zwei völlig getrennte Welten aufzubauen.
Beispiel: Leistungsseite → geführte Anfrage → geschützter AuftragsstatusAuf jedem vorgesehenen Gerät sinnvoll bedienbar
Nicht nur die Bildschirmgröße wird angepasst. Navigation, Formulare und Arbeitsansichten werden für Büro, Tablet vor Ort und Smartphone unterschiedlich priorisiert.
Beispiel: vollständige Disposition im Büro, kompakte Checkliste beim KundenBestehende Systeme können angebunden werden
Kalender, Buchhaltung, Warenwirtschaft, Dokumentenspeicher oder Zahlungsanbieter werden über kontrollierte Datenwege verbunden, wenn das wirtschaftlich und technisch sinnvoll ist.
Beispiel: freigegebene Auftragsdaten an die vorhandene Buchhaltung übergebenÄnderungen bleiben nachvollziehbar
Quellcode, Konfiguration und Veröffentlichungen werden versioniert. Prüfungen und getrennte Umgebungen reduzieren das Risiko, dass eine Änderung unkontrolliert den laufenden Betrieb beeinflusst.
Beispiel: neue Funktion zuerst in einer Prüfversion, danach kontrolliert produktivBetrieb und Wiederherstellung werden mitgeplant
Hosting, Zugänge, Protokollierung, Sicherungen und Überwachung richten sich nach den verarbeiteten Daten und der betrieblichen Bedeutung der Lösung.
Beispiel: andere Betriebsanforderungen für eine Website als für ein täglich genutztes KundenportalSie bleiben nicht von einem Plug-in-Markt abhängig
Notwendige Funktionen werden gezielt ausgewählt oder entwickelt. Dadurch bestimmen nicht zufällige Erweiterungen fremder Anbieter über Datenschutz, Bedienung und Weiterentwicklung.
Bestehende Standardlösungen bleiben möglich, wenn sie den Kernbedarf verlässlich erfüllen.Qualität entsteht im Entwicklungsweg
Versionierte ÄnderungenAutomatisierte PrüfungenGetrennte UmgebungenKontrollierte Veröffentlichung
Wenig unnötiger Code, optimierte Medien und eine passende Auslieferungsstrategie.
Begrenzte Angriffsfläche, aktuelle Abhängigkeiten und klare Zugriffswege.
Verständliche Module, dokumentierte Schnittstellen und reproduzierbare Builds.
Auf Leistungs- und Branchenseiten sprechen wir deshalb hauptsächlich über Aufgaben, Nutzer und Ergebnisse. Diese Seite dokumentiert die technische Haltung für alle, die genauer wissen möchten, worauf ihre Lösung aufbaut.
WordPress, individueller Aufbau oder Baukasten?Technische Fragen – in verständlichen Antworten.
Sie müssen kein Technikteam mitbringen. Diese Antworten zeigen, welche Entscheidungen wir übernehmen und wo Ihr betrieblicher Kontext unverzichtbar bleibt.
Müssen wir uns vor dem Projekt für React, Next.js oder ein anderes System entscheiden?
Nein. Sie beschreiben Ziel, Nutzer, vorhandene Systeme und betriebliche Anforderungen. Daraus leiten wir ab, welche technische Grundlage angemessen ist. Eine öffentliche Website, ein geschütztes Portal und eine geschäftskritische Anwendung können unterschiedliche Schwerpunkte haben. Die Auswahl wird begründet und im Projekt dokumentiert.
Warum setzt CGN nicht mehr automatisch auf WordPress?
WordPress kann für bestimmte, redaktionell geprägte Websites weiterhin geeignet sein. Für individuelle Abläufe, Portale und eng angebundene Funktionen entstehen jedoch häufig viele Plug-in-Abhängigkeiten, zusätzliche Pflege und Kompromisse bei Bedienung oder Datenwegen. Deshalb prüfen wir heute zuerst, ob eine schlankere, gezielt entwickelte Weblösung langfristig besser passt – statt ein System unabhängig von der Aufgabe vorzugeben.
Können wir Inhalte später selbst bearbeiten?
Ja, wenn das für den Alltag sinnvoll ist. Dafür kann ein passender redaktioneller Bereich oder ein sogenanntes Headless-CMS angebunden werden. Vorher klären wir, welche Inhalte tatsächlich regelmäßig geändert werden, wer sie freigibt und welche Bedienung benötigt wird. Eine umfangreiche Redaktion wird nicht eingebaut, wenn nur selten einzelne Texte angepasst werden.
Sind wir nach der Entwicklung technisch an CGN gebunden?
Für individuelle Projekte werden Übergabe, Nutzungsrechte, Betrieb und Wartung vor der Umsetzung vertraglich geklärt. Quellcode, Konfiguration, Abhängigkeiten und Betriebswissen sollen nachvollziehbar bleiben. Ob die Lösung bei CGN betrieben, an eine geeignete Infrastruktur übergeben oder gemeinsam mit einem weiteren IT-Dienstleister betreut wird, richtet sich nach dem vereinbarten Modell.
Lassen sich bestehende Kalender, Buchhaltung oder Fachprogramme weiterverwenden?
Oft ja. Wir prüfen zuerst, welches System fachlich führend bleiben soll und welche dokumentierten Schnittstellen verfügbar sind. Anschließend wird nur der notwendige Datenaustausch geplant. Fehlt eine belastbare Schnittstelle, benennen wir die Einschränkung, statt eine fragile Verbindung als sichere Integration zu verkaufen.
Funktioniert eine Webanwendung auch auf Tablet und Smartphone?
Webanwendungen können für Desktop, Tablet und Smartphone geplant werden. Dabei wird nicht lediglich dieselbe große Oberfläche verkleinert. Für jedes Gerät werden die dort wichtigen Aufgaben priorisiert – zum Beispiel vollständige Planung im Büro und eine kurze Checkliste mit Foto-Upload beim Kunden. Offlinefähigkeit ist eine zusätzliche Anforderung und wird gesondert geprüft.
Wie bleibt die Lösung später erweiterbar?
Ein klar abgegrenzter erster Umfang, nachvollziehbare Datenmodelle, getrennte Module und dokumentierte Schnittstellen schaffen die Grundlage. Erweiterbar bedeutet allerdings nicht, dass jede spätere Idee kostenlos oder ohne technische Entscheidung ergänzt werden kann. Neue Funktionen werden anhand ihres Nutzens und ihrer Auswirkungen auf Sicherheit, Daten und Betrieb bewertet.
Welche Systeme sind bei Ihnen bereits gesetzt?
Wir prüfen, was bleiben kann, was verbunden werden sollte und wo eine neue Komponente sinnvoll ist.