Häufig gestellte Fragen

MS WebX ist ein IT-Unternehmen. Wir bauen Websites und Web-Plattformen, native Apps für iOS und Android und integrieren KI darin — dazu die SEO-Arbeit, die das Gebaute auffindbar macht. Wir betreiben außerdem eigene Produkte auf derselben Plattform, die wir für Kunden einsetzen. Die Basis läuft also im Echtbetrieb, bevor sich jemand anderes darauf verlässt.

Beides, und zwar bewusst. Was wir anbieten, läuft zuerst in unseren eigenen Produkten — das mehrsprachige Seitensystem, die API-Schicht, die Admin-Werkzeuge, die Analytics. Kundenprojekte starten nicht auf einem ungetesteten Fundament, und wenn im Kern etwas kaputtgeht, merken wir es vor dem Kunden.

Auf drei Wegen, die alle unabhängig von dem sind, was hier steht. Das Impressum dieser Seite enthält die rechtlichen Unternehmensangaben. Unsere eigenen Produkte sind öffentlich und ohne Kontaktaufnahme nutzbar. Und über die Kontaktseite erreicht man dieselben Leute, die den Code schreiben — kein Callcenter davor.

Du beschreibst das Ziel, nicht die technische Lösung. Wir fragen so lange nach, bis der Umfang wirklich klar ist, und halten ihn schriftlich fest, bevor gebaut wird. Wenn wir den gewünschten Weg für den falschen halten, sagen wir das vorher — dieses Gespräch ist billiger als der Umbau, den es verhindert.

In kleinen, sichtbaren Schritten. Die Arbeit landet auf einer Staging-Umgebung, die du jederzeit im Browser öffnen kannst, und geht erst live, wenn du es sagst. Niemand sieht das fertige Produkt zum ersten Mal am Projektende — dann ist jede Änderung teuer.

Was wir bauen, ist zum Pflegen gedacht: Updates der Abhängigkeiten, Monitoring und Änderungen, wenn sich dein Geschäft ändert. Ob wir das weiterführen oder dein eigenes Team übernimmt, wird im Projekt vereinbart und nicht hinterher unterstellt. Nichts wird so gebaut, dass nur wir daran arbeiten können.

Wir lesen zuerst den vorhandenen Code und sagen dann klar, ob Weiterführen oder Ersetzen über die Lebensdauer günstiger ist. Beide Antworten kommen vor — geerbter Code ist oft völlig in Ordnung und nur schlecht dokumentiert. Wir empfehlen keinen Neubau aus Reflex, denn ein Neubau ist das Teuerste, was man dir verkaufen kann.

PHP auf dem Server, TypeScript im Browser, Flutter für iOS und Android, MariaDB für die Daten, nginx und FrankenPHP für die Auslieferung. Bewusst aktuelle, weit verbreitete Technik, damit sie nach uns jeder pflegen kann. Qualität sichern Maschinen statt guter Vorsätze: die statische Analyse läuft auf der strengsten Stufe ohne Ausnahmeliste, dazu über zweihundert projekteigene Regeln, die abdriftenden Code sofort ablehnen.

Eine Codebasis mit gemeinsamem Kern und einer dünnen Schicht je Marke darüber. Jede Marke hat eigenes Design, eigene Inhalte, eigene Datenbank und eigene Domain, während Sicherheits-Fixes, Performance-Arbeit und neue Kernfunktionen überall gleichzeitig ankommen statt von Hand in jede Seite kopiert zu werden. Eine Marke dazuzunehmen ist Konfiguration und Inhalt, kein Fork.

Ja, und strenger, als dieser Satz sonst gemeint ist. Die API wird einmal in PHP definiert, und sowohl der TypeScript-Client fürs Web als auch der Dart-Client für die App werden daraus generiert. Keiner wird von Hand geschrieben — der Linter weist einen handgeschriebenen API-Typ ab. Die App kann also nicht still auseinanderlaufen: Eine Abweichung bricht den Build statt die Produktion.

Echt. Jede Seite existiert je Sprache als eigener Datensatz mit eigenem Text und eigener URL — diese FAQ liegt auf Englisch unter /frequently-asked-questions und auf Deutsch unter /de/haeufig-gestellte-fragen, nicht hinter einem Übersetzungsparameter. Dadurch lässt sich jede Sprache so schreiben, wie im jeweiligen Markt tatsächlich gesucht wird, und in einer Sprache korrigieren, ohne die anderen siebzehn anzufassen.

Genau dafür ist sie gebaut. Jede Marke hat eigene Datenbank, eigene Domain und eigene Inhalte — eine Marke kann die Daten einer anderen nicht lesen, und ein Inhaltsfehler in der einen taucht nicht in der anderen auf. Geteilt wird der Motor: Routing, API-Schicht, Admin-Werkzeuge und die Sicherheitsarbeit.

Cannabivo ist live: eine Suchmaschine für Social Clubs, in der Besucher Clubs nach Ort finden und vergleichen und Clubs ihren eigenen Eintrag pflegen. Steel ist ein Nachschlagewerk für Werkstoff-Äquivalente für Technik und Einkauf; es befindet sich in der Entwicklung und ist noch nicht öffentlich. Beide laufen auf der Plattform, die in diesem Bereich beschrieben ist.

Dir. Wir verarbeiten sie, um den beauftragten Dienst zu betreiben, und für sonst nichts. Sie werden nicht mit Daten anderer Kunden zusammengeworfen, nicht verkauft und nicht genutzt, um deinen Nutzern Werbung auszuspielen. Endet die Zusammenarbeit, nimmst du die Daten mit.

Die Verbindungen laufen über HTTP/3, und die Domain steht auf der vorinstallierten HSTS-Liste der Browser — ein Browser spricht also schon beim allerersten Besuch nicht unverschlüsselt mit ihr, bevor irgendeine Weiterleitung abgefangen werden könnte. Der Schlüsselaustausch ist post-quanten-fähig: X25519 kombiniert mit ML-KEM-768 — so gewählt, dass heute mitgeschnittener Verkehr auch dann noch standhält, wenn Quantenrechner ihn angreifen können.

Niemals im Quellcode — das erzwingt der Build, nicht die Disziplin: Code mit einem fest eingetragenen Geheimnis wird abgelehnt, bevor er gemerged werden kann. Geheimnisse liegen verschlüsselt in einem Einstellungsspeicher und werden zur Laufzeit nur dort entschlüsselt, wo sie wirklich gebraucht werden. Ein Schlüsselwechsel ist damit eine Änderung an einer Stelle statt einer Suche durch die ganze Codebasis.

Ja. Anwendungsereignisse, Fehler und administrative Aktionen werden in die Datenbank geschrieben statt in Textdateien, die über Server verstreut liegen — dadurch sind sie tatsächlich durchsuchbar. Administrative Änderungen halten fest, wer gehandelt hat, was geändert wurde und wann. Auf „wer hat letzten Monat diesen Preis geändert“ gibt es eine Antwort statt einer Vermutung.

Nicht notwendige Cookies werden erst gesetzt, wenn der Besucher zustimmt, die Entscheidung wird festgehalten, und jede Seite, die wir bauen, hat eine Stelle, an der sie später geändert oder widerrufen werden kann. Ablehnen ist ein Klick und keine Suche durch ein Einstellungsmenü — und wer ablehnt, bekommt trotzdem eine funktionierende Seite.

Ein Modell erledigt eine klar umrissene Aufgabe in deinem Produkt und schlägt dabei messbar die Alternative — eingehende Nachrichten sortieren, Texte entwerfen, die ein Mensch danach freigibt, die Suche verstehen lassen, was jemand meinte statt was er tippte. Es ist keine Chat-Blase, die man auf eine fertige Website klebt. Die nützliche Frage lautet nie „können wir KI einbauen“, sondern „welche wiederkehrende Aufgabe kostet dich gerade Zeit“.

Bei Inhalten. Unser mehrsprachiges Material entsteht und bleibt aktuell mit Modellunterstützung und wird vor der Veröffentlichung je Sprache geprüft — nie direkt aus dem Modell publiziert. Genau deshalb sind wir beim Thema KI vorsichtig: Wir wissen aus eigener Arbeit, wo die Ausgabe stark ist und wo sie noch einen Menschen braucht.

Bevor gebaut wird, benennen wir schriftlich, welcher Anbieter welche Daten verarbeitet und was davon gespeichert bleibt. Ist diese Antwort für dich nicht akzeptabel, wird die Funktion anders entworfen oder gar nicht gebaut. Keine Daten verlassen dein System auf eine Weise, der du nicht zugestimmt hast — und „wir wussten nicht, dass das rausgeht“ ist kein Ergebnis, das wir zu liefern bereit sind.