Zum Inhalt springen
megapromotingLassen Sie uns sprechen

Expertise · Websites

Diese Website ist unsere technische Spezifikation — einschließlich der Messungen, die uns nicht zugutekommen.

Wir bauen serverseitig gerenderte Websites, mit Bildern in AVIF und WebP, von außen überprüften Sicherheits-Headern, aus Daten generierter Sitemap und einer Akzeptanzprüfung, die nach jeder Veröffentlichung ausgeführt wird. Alles lässt sich auf der Seite prüfen, die Sie gerade lesen.

Bereits gebautWir können keine Kundenseite ohne dessen Zustimmung zitieren, aber wir brauchen es nicht: Der Beweis ist genau diese Seite. Sie läuft mit Next.js 16.2.4 und React 19.1.0, wird prerendert aus dem Cache ausgeliefert (`x-nextjs-prerender: 1`, `x-nextjs-cache: HIT`), trägt HSTS mit `preload`, `nosniff`, `SAMEORIGIN`, `Referrer-Policy` und eine vollständige Content-Security-Policy — geprüft mit `curl -I` am 06.09.2026. Die Sitemap enthält 147 Adressen, alle aus Daten generiert, nicht von Hand geschrieben. Die zweite Implementierung im selben Depot: die Formularinfrastruktur — Append-only-Log, öffentliche Health-Sonde, Ratenbegrenzung — und das nach der Veröffentlichung ausgeführte Abnahmeskript.

Eine Präsentationswebsite hat nur einen ehrlichen Test: Können Sie von außen überprüfen, was das Unternehmen darüber sagt? Deshalb zählt diese Seite keine Technologien auf, sondern Dinge, die Sie mit einem Befehl selbst kontrollieren können. Die Website läuft mit Next.js 16.2.4 und React 19.1.0, und die Seiten werden beim Build prerendert und aus dem Cache ausgeliefert — das sieht man an den Antwort-Headern: `x-nextjs-prerender: 1`, `x-nextjs-cache: HIT`, `s-maxage=31536000`, mit einem Fenster von 300 Sekunden, in dem eine alte Seite noch ausgeliefert werden kann, während sie aktualisiert wird.

Serverseitiges Rendering ist keine Architekturvorliebe. Ein Besucher mit schwacher Verbindung und eine Suchmaschine erhalten dasselbe vollständige HTML, ohne auf JavaScript zu warten. Dazu kommt die Ressourcen-Disziplin: Bilder werden als AVIF und WebP ausgeliefert, mit einem Cache von einem Jahr; Schriftarten werden von uns gehostet, nicht von einem externen Dienst angefordert; acht UI-Bibliotheken haben optimierte Importe, damit nicht ganze Module wegen eines einzigen Symbols geladen werden.

Sicherheitsheader werden aus zwei Stellen gesendet und in der echten Antwort geprüft, nicht nur in der Konfiguration: erzwungener sicherer Transport für zwei Jahre mit Subdomains und Aufnahme in die Preload-Liste, Verbot der Typenerratung von Dateien, Einschränkung der Einbettung in fremde Frames, Referrer-Policy und eine Permissions-Policy, die die Kamera sperrt und das Mikrofon nur für die eigene Origin zulässt — denn Sprachdemonstrationen brauchen es, und ohne diese Ausnahme verweigert der Browser stillschweigend.

Der letzte Teil ist der, der uns unterscheidet, und er ist unangenehm: Wir veröffentlichen auch, was wir bei uns schlecht gemessen haben. Der Server bietet noch kein Brotli und auch kein HTTP/2 an. Der Übersetzungskatalog wird bei jedem Aufruf übertragen und kostet jedes Mal ungefähr 70 KB komprimiert. Ein Paket von 443 KB enthält vier Sprachkataloge, von denen nur einer routbar ist. Die Schriftarten bringen auch den kyrillischen Subsatz mit, obwohl die geprüften Seiten kein einziges kyrillisches Zeichen enthalten. Diese Zahlen sind gemessen, im Repository und in der Reparaturliste festgehalten. Ein Anbieter, der keine solchen Zahlen über seine eigene Website hat, hat entweder nicht gemessen oder will es nicht sagen.

Was dazugehört

Die Arbeit, nach Bestandteilen

Serverseitiges Rendering, aus dem Cache ausgeliefert

Die Seiten werden beim Build vorgerendert und als vollständiges HTML ausgeliefert, nicht im Browser aufgebaut. In der echten Antwort erscheinen `x-nextjs-prerender: 1` und `x-nextjs-cache: HIT`, mit `cache-control: s-maxage=31536000` und einem Fenster von 300 Sekunden, in dem die alte Version noch ausgeliefert werden kann, während sie aktualisiert wird. Der praktische Effekt: Ein Besucher mit schwacher Verbindung und ein Crawler erhalten denselben Inhalt, in derselben Anfrage.

Bilder und Schriftarten mit Budget, nicht mit Glück

Die konfigurierten Formate sind AVIF und WebP, mit einer minimalen Cache-Dauer von 31.536.000 Sekunden — ein Jahr — und dem Header `immutable` für statische Dateien, Bilder und Schriftarten. Die Schriftarten werden bei der Erstellung von uns gehostet, nicht bei jedem Besuch von einem externen Dienst angefordert, und sie werden mit `swap` angezeigt, damit der Text vor dem Herunterladen der Schriftart erscheint. Es gibt auch ein Batch-Komprimierungsskript mit Qualität 80 für WebP und 75 für AVIF, damit die Quelle nicht davon abhängt, was jemand aus dem Grafikeditor exportiert hat.

Sicherheitsheader aus zwei Stellen gesendet und in der Antwort geprüft

Aus der Anwendung: erzwungener sicherer Transport für 63.072.000 Sekunden mit Subdomains und Aufnahme in die Preload-Liste, `X-Content-Type-Options: nosniff`, `X-Frame-Options: SAMEORIGIN`, `Referrer-Policy: strict-origin-when-cross-origin` und eine Permissions-Policy, die die Kamera sperrt, das Mikrofon nur für die eigene Origin zulässt und Interest Cohort deaktiviert. Vom Webserver separat: eine vollständige Content-Security-Policy mit der expliziten Liste erlaubter Origins. Bei der Übergabe wird ausdrücklich geschrieben, dass es zwei Stellen sind — sonst sucht der Nächste, der etwas ändert, an der falschen Stelle.

Sitemap aus Daten erzeugt, nicht von Hand geschrieben

Die Sitemap wird aus fünf Quellen aufgebaut — 13 feste Adressen, die Artikel, 19 Produkte, 12 Dienstleistungen und 100 Kombinationen Dienstleistung × Bereich — und durchläuft am Ende eine Deduplizierung. Das Ergebnis: 147 Adressen, sowohl im Code als auch in der Produktionsdatei gezählt. Eine neue Seite kommt automatisch hinzu; eine gelöschte verschwindet. Niemand pflegt eine parallele Liste, die sich in drei Wochen asynchronisiert.

Alte Adressen sterben nicht: 43 permanente Weiterleitungen

Eine Bereinigung der Struktur hinterlässt Adressen, die jemand gespeichert hat oder veröffentlicht hat. In der Konfiguration gibt es 43 permanente Weiterleitungen — 9 Leitfäden zum Blog, 20 verwaiste Artikel, 6 umgemappte Fallstudien und 8 Einzelseiten. Es gibt auch 11 Seiten, die aus der Anwendung heraus weiterleiten; sie sind funktional korrekt, aber teurer als eine Konfigurationsregel und werden entsprechend in der Reparaturliste vermerkt.

Das Formular ist Infrastruktur, nicht Dekor

Die Anfrage wird vor dem Versuch der Zustellung in ein Append-only-Log geschrieben, mit einer zweiten Zeile für das Ergebnis; es gibt eine öffentliche Gesundheitsprüfung, die sagt, ob ein Lead gerade jetzt einen Menschen erreichen kann; und Anfragen an die Schnittstellen sind auf 10 pro Minute begrenzt, mit dem Schlüssel aus dem letzten Hop des Weiterleitungs-Adress-Headers, nicht aus dem ersten — der erste wird vom Client gesendet. Die Gründe sind im Code festgehalten, nicht in separater Dokumentation.

Abnahmeprüfung nach jeder Veröffentlichung

Ein Skript öffnet jede Produktseite, in Gruppen von drei, und schlägt fehl, wenn der 200-Code, der Fragen-Anker, der Beispiel-Anker oder die kanonische Adresse fehlt. Danach prüft es die Sitemap — sie muss jedes Produkt enthalten und darf keine nicht öffnbaren Sprachvarianten enthalten — und `robots.txt`, damit keine für das Rendering benötigten Ressourcen blockiert werden. Jede Prüfung entspricht etwas, das bereits einmal kaputtgegangen ist.

Kanonische Adresse einmalig aufgelöst, für die gesamte Website

Die kanonische Adresse ist relativ, an einer einzigen Stelle in der Grundkonfiguration, deklariert und wird für jede Route einzeln aufgelöst. Dieselbe Lösung gilt für die Social-Sharing-Adresse, die zuvor auf den meisten Seiten die Startseite deklarierte. Es ist eine Codezeile, die eine Konvention ersetzt, die sich jede neue Seite selbst hätte merken müssen — und die sie sich unweigerlich nicht merkt.

Was nicht funktioniert, steht im Repository, neben dem Code

Das Repository enthält eine Datei mit bekannten Fehlern, die erklärt, warum beispielsweise die Sprachvarianten in der Adresse die Sprache nicht umschalten, warum die offensichtliche Lösung die Dinge verschlimmert — beim serverseitigen Rendern gibt es weder Local Storage noch Browser, daher fällt der Detektor auf Englisch zurück und alle Seiten erscheinen auf Englisch — und welche die beiden echten Lösungen sind. Wir bevorzugen es, wenn ein technischer Käufer die von uns geschriebene Grenze findet, nicht die von ihm entdeckte.

Wie es aussieht

Der Weg, Schritt für Schritt.

01

Das Inventar der Adressen und was mit den alten geschieht

Die erste Lieferung ist die Liste der vorhandenen Adressen und die Entscheidung für jede: bleibt, wird umgeleitet oder verschwindet. Auf dieser Website haben sich 43 permanente Weiterleitungen ergeben. Es ist die Arbeit, die alle überspringen und die einige Monate später Fehlerseiten in den Suchergebnissen erzeugt.

02

Die Inhaltsstruktur und die Quellen, aus denen sie generiert wird

Die Produkt- und Serviceseiten werden aus Daten aufgebaut, nicht aus separaten Dateien. Daher stammen die automatisch generierte Sitemap, die konsistenten kanonischen Adressen und die Möglichkeit, programmatisch zu prüfen, ob jede Seite das hat, was sie haben muss. Wir liefern die Datenstruktur, nicht nur die daraus gerenderten Seiten.

03

Der Aufbau mit vor dem Inhalt festgelegten Budgets

Wir legen von Anfang an fest, in welchem Format die Bilder vorliegen, was und wie lange gecacht wird, was serverseitig gerendert wird und was im Browser interaktiv bleibt. Der Inhalt wird dann in dieses Budget eingeordnet. Die umgekehrte Reihenfolge erzeugt Websites, die zum Start gut aussehen und mit jeder hinzugefügten Seite schwerfälliger werden.

04

Die Veröffentlichung mit Gate und Abnahmeprüfung

Die Veröffentlichung prüft den freien Speicher des Servers, führt das Sicherheitsaudit der Abhängigkeiten aus, baut aus einem sauberen Zustand und bestätigt, dass der Prozess läuft, bevor Erfolg gemeldet wird. Unmittelbar danach öffnet das Abnahmeskript die Seiten und prüft Anker, kanonische Adressen, Sitemap und `robots.txt`. Beide werden übergeben, nicht bei uns behalten.

05

Die Übergabe mit der Liste der Lücken und Messwerte

Wir übergeben den Code, das Veröffentlichungsverfahren, das Rollback-Verfahren, die Gesundheitsadressen — und die schriftliche Liste dessen, was nicht abgedeckt ist, mit Zahlen. Für diese Website umfasst die Liste das Fehlen von Brotli und HTTP/2 auf dem Server, die Kosten des Übersetzungskatalogs bei jeder Navigation und das ungenutzte Teilset an Schriftarten. Wir bevorzugen, dass die Liste von uns kommt.

Vier von außen überprüfbare Schichten1Vorrendertes HTML aus dem Cache ausgeliefert2AVIF/WebP-Bilder und lokal gehostete Schriftarten3Sicherheits-Header aus der Anwendung und vom Webserver4die Sitemap und die kanonischen, aus Daten generierten Adressen
Vier von außen überprüfbare Schichten

Die Daten

Was wir anfassen, wo die Daten liegen und wie lange sie bleiben

Die Fragen, die jede Person mit einem Datenschutzbeauftragten stellt — hier gestellt, bevor er sie stellt.

Die Daten aus dem Kontaktformular
Name, E-Mail-Adresse, Telefon, Unternehmen, gewählter Service, Nachricht, Herkunftsseite und Netzwerkpräfix des Besuchers. Sie werden in einem Protokoll auf dem eigenen Server mit den Rechten `0700` für das Verzeichnis und `0600` für die Dateien außerhalb des Versionsverzeichnisses gespeichert. Frist: 24 Monate, vom Code bei jedem Schreiben angewendet, nicht von einem Planer, der vergessen werden kann.
Die IP-Adresse, vor dem Schreiben gekürzt
Es wird nur das Netzwerkpräfix gespeichert — `/24` bei IPv4, `/48` bei IPv6 — und der letzte Hop aus dem Header ausgelesen, weil der erste vom Client gesendet wird und nichts beweist. Dieselbe Funktion wird auch von der Ratenbegrenzung verwendet, daher gibt es keinen zweiten Ort, an dem die vollständige Adresse versehentlich landen könnte.
Traffic-Statistiken
Die Messung läuft über das konfigurierte Analysewerkzeug und wird nach Einwilligung aktiviert. Die realen Cookies wurden empirisch auf der Live-Website vor und nach der Zustimmung überprüft, und die Cookie-Richtlinie wurde nach dieser Überprüfung umgeschrieben — nicht umgekehrt. Die vorherige Richtlinie führte Cookies auf, die nicht existierten.
Verzeichnis der Verarbeitungen, versioniert neben dem Code
Jeder vom Site berührte Datentyp hat einen Eintrag mit Zweck, Rechtsgrundlage, Kategorien und Frist in einem Dokument, das im selben Repository geführt wird. Wenn der Code eine Frist ändert, ändert sich das Dokument im selben Commit. Was nicht festgelegt ist — zum Beispiel die tatsächliche Aufbewahrungsdauer im Analysekonto — wird ausdrücklich als zu klärendes Element markiert, nicht als Tatsache erklärt.
Was nicht vom Server ausgeht
Benachrichtigungstoken, Anbieterschlüssel und Kanal-Identifikatoren. Die Health-Sonde liefert ausschließlich logische Werte zurück, gerade damit sie von einem externen Dienst abgefragt werden kann, ohne etwas über die Konfiguration preiszugeben.

Ein Fall

Was das Audit der eigenen Website zeigt, wenn Sie sie vollständig veröffentlichen

Die Ausgangslage

Nach einer Umstrukturierung wirkte die eigene Website in Ordnung: Alle Seiten antworteten mit 200, das Dashboard war grün. Wir haben uns die Frage gestellt, die wir auch Kunden stellen: Was sagt eine von außen durchgeführte Messung über alle Adressen gleichzeitig, nicht nur über die Startseite?

Was wir gebaut haben

Wir haben jede bekannte Adresse mit direkten Anfragen durchlaufen — 249 Adressen, 23 Spalten pro Adresse, ohne Verfolgung der Weiterleitungen, mit höchstens sechs parallelen Anfragen — und das Ergebnis in eine versionierte Tabellendatei geschrieben. Darüber haben wir separate Prüfungen ausgeführt: die tatsächliche HTML-Komprimierung, was bei jeder Navigation übertragen wird, was die JavaScript-Pakete enthalten, welche Schriftarten geladen werden, welche Cache- und Transport-Header der Server bietet. Jede Zahl wurde in der echten Antwort überprüft, nicht aus der Konfiguration abgeleitet.

Was dabei herauskam

244 Adressen antworten mit 200 und 5 leiten um. 131 Seiten hatten keine kanonische Adresse, und 219 von 244 erklärten die Startseite zur Freigabeadresse — beides jetzt mit je einer Zeile in der Grundkonfiguration repariert, die auf jede Route angewendet wird. Der Server bietet weder Brotli noch HTTP/2. Der Übersetzungskatalog mit 2.268 Schlüsseln wird bei jeder Navigation übertragen und kostet jedes Mal ungefähr 70 KB komprimiert. Ein 443-KB-Paket enthält vier Sprachkataloge, von denen nur einer routbar ist. Die Schriftarten bringen auch den kyrillischen Subset mit, obwohl die geprüften Seiten kein einziges kyrillisches Zeichen enthalten. Alle Zahlen, mit den Befehlen, die sie reproduzieren, sind im Repository dokumentiert.

Was der Fall nicht sagt

Es sind Labor-Messungen, von außen mit direkten Anfragen durchgeführt. Es sind keine Felddaten von echten Besuchern, und wir stellen sie nicht so dar: Die Metriken zur wahrgenommenen Ladezeit konnten im verwendeten Werkzeug nicht ausgelesen werden und sind ausdrücklich als nicht gemessen markiert. Wir haben den Build der Anwendung während des Audits nicht ausgeführt, weil mehrere Personen am selben Checkout gearbeitet haben.

Fragen

Was uns die Leute fragen, bevor sie anrufen

Womit bauen Sie konkret?

Next.js 16.2.4 mit React 19.1.0 und TypeScript, mit Tailwind für Styles und barrierefreien UI-Komponenten auf Basis von Radix-Primitiven. Die Seiten werden beim Build vorgerendert und aus dem Cache ausgeliefert — das lässt sich von außen prüfen: Die Antwort-Header enthalten `x-nextjs-prerender: 1` und `x-nextjs-cache: HIT`. Das ist keine Liste von Technologien, die wir gelesen haben; es ist der Stack, auf dem die Seite läuft, die Sie gerade lesen.

Wie prüfe ich selbst, was Sie über Sicherheit sagen?

Mit einem einzigen Befehl: `curl -I https://www.megapromoting.com/servicii`. Sie werden `strict-transport-security: max-age=63072000; includeSubDomains; preload`, `x-content-type-options: nosniff`, `x-frame-options: SAMEORIGIN`, `referrer-policy: strict-origin-when-cross-origin`, eine Berechtigungsrichtlinie sehen, die die Kamera schließt und das Mikrofon nur für die eigene Origin zulässt, plus eine Content-Security-Policy mit der expliziten Liste der Origins. Die ersten fünf stammen aus der Anwendungskonfiguration; die letzte wird vom Webserver gesendet — zwei verschiedene Stellen, und wir schreiben das bei der Übergabe so auf.

Woher wissen Sie, dass Sie bei der letzten Veröffentlichung nichts kaputtgemacht haben?

Aus einem nach der Veröffentlichung ausgeführten Abnahmeskript. Es öffnet jede Produktseite und schlägt fehl, wenn der 200-Code, der Fragen-Anker, der Beispiel-Anker oder die kanonische Adresse fehlt; danach prüft es, dass die Sitemap jedes Produkt enthält und keine Sprachvarianten enthält, die nicht geöffnet werden, und dass `robots.txt` die Rendering-Ressourcen nicht blockiert. Jede Prüfung in der Liste entspricht etwas, das bereits einmal kaputtgegangen ist. Das Skript wird zusammen mit dem Projekt übergeben — Sie können es auch selbst ausführen.

Ist Ihre Website schnell?

Es hängt davon ab, was Sie messen, und wir haben in beide Richtungen Zahlen. Gut: Die Seiten sind prerendert und aus dem Cache ausgeliefert, Bilder werden in AVIF und WebP mit einem einjährigen Cache erzeugt, Schriftarten werden lokal gehostet. Schlecht, am eigenen Standort gemessen: Der Server bietet weder Brotli noch HTTP/2 an — eine Anfrage mit `Accept-Encoding: br` erhält eine unkomprimierte Antwort; der Übersetzungskatalog wird bei jeder Navigation übertragen und kostet jedes Mal ungefähr 70 KB komprimiert; ein Paket von 443 KB enthält vier Sprachkataloge, von denen nur einer routbar ist. Ich gebe Ihnen keinen Laborwert; ich gebe Ihnen die gemessenen Bytes und die Liste der Reparaturen, die sich daraus ergibt.

Wer pflegt die Sitemap?

Niemand, und das ist die richtige Antwort. Sie wird aus fünf Datenquellen generiert — festen Adressen, Artikeln, Produkten, Dienstleistungen und den Kombinationen Dienstleistung × Bereich — und durchläuft eine finale Deduplizierung. Es kommen 147 Adressen heraus, dieselbe Zahl im Code und in der in Produktion ausgelieferten Datei. Eine neue Seite kommt automatisch dazu. Was heute fehlt, um es offen zu sagen: Die Einträge tragen kein Datum der letzten Änderung, und 93 indexierbare Adressen sind noch nicht in der Sitemap. Sie stehen in der Reparaturliste, nicht versteckt.

Machen Sie mehrsprachige Websites?

Hier muss ich präzise sein, weil dies die klarste Grenze dieser Website ist. Das Umschalten der Sprache über die Adresse funktioniert nicht: Die Konfiguration fixiert Rumänisch, also liest der Detektor den Parameter nie. Ich habe im Repository geschrieben, warum die naheliegende Lösung schlechter ist — beim Server-Rendering gibt es weder lokalen Speicher noch Browser, also fällt der Detektor auf Englisch zurück und alle Seiten erscheinen auf Englisch — und was die zwei echten Lösungen sind: Pfadrouten mit Sprachsegment oder serverseitige Sprachauflösung auf jeder Seite. Die erste ist empfohlen. Für ein neues Projekt starten wir direkt mit Pfadrouten; für ein bestehendes ist es eine Arbeit, keine Einstellung.

Was passiert mit alten Adressen, wenn Sie eine Website neu erstellen?

Sie werden inventarisiert und erhalten jeweils eine Entscheidung: bleibt, wird dauerhaft weitergeleitet oder verschwindet. Bei der Bereinigung dieser Website kamen 43 Weiterleitungen in der Konfiguration heraus. Es gibt außerdem 11 Seiten, die intern in der Anwendung weiterleiten — sie funktionieren, bauen aber die Seite auf, bevor sie die Weiterleitungsantwort senden, was Verschwendung ist; sie stehen in der Liste der in die Konfiguration zu verlegenden Einträge. Ich sage Ihnen das, damit Sie wissen, welche Art von Liste Sie bei der Übergabe erhalten.

Woher weiß ich, dass das Formular wirklich liefert?

Sie fragen es selbst: `GET /api/health/contact` antwortet mit 200, wenn ein Lead jetzt zu einem Menschen gelangen kann, und mit 503, wenn nicht, wobei separat geprüft wird, dass das Token des Benachrichtigungskanals gültig ist und das Anfragenprotokoll geschrieben werden kann. Die Antwort enthält nur logische Werte, niemals das Token. Es existiert, weil genau hier einmal etwas gebrochen ist: das widerrufene Token, die Route lieferte 500 zurück, Anfragen gingen spurlos verloren. Jetzt wird die Anfrage protokolliert, bevor die Zustellung versucht wird.

Was machen Sie nicht?

Wir versprechen keine Suchpositionen, Conversion-Prozente oder Leistungswerte, die wir an Ihrem Projekt nicht gemessen haben. Wir liefern keine Website ohne Liste alter Adressen und ohne Rückkehrverfahren. Wir übernehmen keine Drittplattformen, auf die wir keinen Zugriff haben. Und wir präsentieren nichts als fertig, was eine bekannte Grenze hat — wenn ich eine Grenze habe, finden Sie sie im Repository beschrieben, bevor Sie sie in Produktion finden.

Worauf die obigen Aussagen beruhen (15 Quellen)
  1. Die Produktion liefert vorgerenderte Seiten aus dem Cache: `x-nextjs-prerender: 1`, `x-nextjs-cache: HIT`, `cache-control: s-maxage=31536000`, `x-nextjs-stale-time: 300`https://www.megapromoting.com/servicii · 2026-09-06
  2. Sicherheits-Header in der echten Antwort: HSTS `max-age=63072000; includeSubDomains; preload`, `nosniff`, `SAMEORIGIN`, `strict-origin-when-cross-origin`, Permissions-Policy mit `microphone=(self)`; plus eine vollständige Content-Security-Policy, ausgeliefert von nginx und ABWESEND in `next.config.ts`https://www.megapromoting.com/servicii · 2026-09-06

13 davon sind Code und Dateien aus unseren Repositories. Wir veröffentlichen weder ihren Namen noch die Zeile: zusammen, auf einer einzigen Seite, würden sie zu genau beschreiben, wie Systeme gebaut sind, die nicht nur uns gehören. Wir gehen sie mit Ihnen durch, im Repository, auf Anfrage — die Überprüfung bleibt möglich, sie findet nur in einem Gespräch statt.

Was sollte bei Ihnen besser laufen?

Erzählen Sie uns von Ihrem Prozess. Gemeinsam legen wir fest, was sich zu bauen lohnt, was wir anbinden können und wie wir das Ergebnis prüfen.

Lassen Sie uns sprechen