Für Verlage und Medienhäuser ist der Inhalt längst nicht mehr das ganze Produkt. Wert entsteht zunehmend in der Plattform, die diesen Inhalt verteilt, monetarisiert und mit der Nutzerin verbindet: Web-Anwendung, Nutzerkonto, Marktplatz, Anzeigen oder Transaktionsschicht. Für CTO und Product Owner folgt daraus ein einfacher, aber anspruchsvoller Schluss: Die Entwicklung von Medien-Anwendungen wird zur fortlaufenden Produktentwicklung und nicht zu einem einmaligen Projekt mit Enddatum.
Aus unserer Erfahrung liegt das Schwierige nicht im Entwurf der ersten Version, sondern darin, das Entwicklungstempo über Jahre zu halten, mit einem Team, das sowohl das Produkt als auch den Traffic darauf versteht. Für einen Marktführer im Medien- und Digitalbereich haben wir genau dieses Team aufgebaut und entwickeln bis heute seine Immobilien-Marktplatzplattform weiter, mit einer Node.js-Architektur, einem Backend in Node und Java und einem React-Frontend.
Warum bauen Medienhäuser heute eigene Apps und digitale Plattformen?
Weil sich verändert hat, womit ein Medienhaus verdient und worüber es konkurriert. Seitenaufrufe allein reichen nicht mehr, und die Leserin will nicht mehr nur lesen, sondern etwas erledigen: ein Angebot finden, vergleichen, Kontakt aufnehmen, kaufen. Ein Verlag, der Vertrauen und Reichweite besitzt, hat einen natürlichen Vorteil, wenn er in die Rolle einer Transaktionsplattform in seiner Nische geht, etwa bei Immobilien, Automobil oder Kleinanzeigen.
Damit verschiebt sich der Schwerpunkt von der Redaktion zum digitalen Produkt. Plötzlich brauchen Sie Nutzerkonto, Suche, Matching-Mechanismen, Zahlungen und ein Panel für die Menschen, die Angebote einstellen. Jedes davon muss nicht nur gebaut, sondern auch betrieben und für wachsenden Traffic weiterentwickelt werden, und das ist eine ganz andere Aufgabe als einen Artikel zu veröffentlichen.
Wie sieht der Weg von der Idee zum funktionierenden Produkt aus?
Wir beginnen mit dem Eingrenzen, nicht mit dem Ausweiten. Statt die ganze Plattform auf einmal zu entwerfen, isolieren wir den einen Pfad, der zuerst funktionieren muss, zum Beispiel ein Inserat einstellen und von einem Käufer gefunden werden. Darum herum legen wir Datenmodell, erste APIs und Oberfläche aus und ergänzen erst dann weitere Module.
Wir arbeiten in einem agilen Rhythmus in kurzen Iterationen, denn ein Medienprodukt korrigiert seine Annahmen ohnehin, sobald es auf echten Traffic trifft. So können wir schnell eine funktionierende Version ausliefern und den Kurs anhand des Nutzerverhaltens korrigieren statt anhand eines Plans vom letzten Quartal. Im Projekt für den Medienmarktführer haben wir Umfang und Arbeitstempo an das Budget des Kunden angepasst, statt vorab einen starren, teuren Plan zu verordnen.
Welche Web-Anwendungen und Marktplätze bauen wir für Medien?
In Projekten für Verlage und Medienhäuser konzentrieren wir uns auf die Schicht, die Nutzer und Transaktion tatsächlich bedient:
- Web-Anwendungen mit Nutzerkonto, Suche und Personalisierung der Inhalte,
- Marktplätze und Anzeigenplattformen, die zwei Marktseiten verbinden,
- Panels für Verkäufer und Redaktion zur Verwaltung von Angeboten und Inhalten,
- Integrationen mit Zahlungssystemen, externen Daten und Analytics-Werkzeugen.
Für den Medienmarktführer haben wir eine Immobilien-Marktplatzplattform gebaut und entwickeln sie weiter, also genau die Art Produkt, in der Inhalt, Inserat und Transaktion an einem Ort zusammentreffen.
Wie sieht ein Medienplattform-Backend in Node.js und Java aus?
Das Backend ist das Herz einer Medienplattform, denn es nimmt den Traffic auf, hält die Logik und liefert die Daten. Wir legen es meist als Satz von Node.js-Services aus, ergänzt um Komponenten in Java dort, wo Reife und Performance eines bestimmten Systemteils zählen. Ein Node.js-Architekt verantwortet das Ganze und setzt Servicegrenzen, API-Verträge und die Art, wie die Module miteinander sprechen.
Diese Trennung erlaubt es, die Plattform weiterzuentwickeln, ohne sie neu zu schreiben. Das Team kann ein neues Modul ergänzen, etwa die Unterstützung eines weiteren Inseratstyps, ohne anzufassen, was bereits funktioniert. Im Marktplatzprojekt waren es genau unsere Node.js-Architekten sowie Node- und Java-Entwickler, die dafür sorgten, dass das Backend eine wachsende Zahl von Angeboten und Abfragen trägt.
Wie bauen wir das React-Frontend einer Medienplattform?
Die Vorderseite einer Medienplattform entscheidet, ob die Nutzerin bleibt. Wir bauen sie in React, in einer Komponentenarchitektur, die es erlaubt, dieselben Elemente, die Angebotsliste, die Filter, die Detailkarte, in verschiedenen Teilen des Produkts wiederzuverwenden. Wir achten darauf, dass Suche und Filterung schnell sind, denn auf einem Marktplatz machen sie aus Besuchern wiederkehrende Nutzer.
Das Frontend verbinden wir über klar beschriebene APIs mit dem Backend, sodass sich beide Schichten im eigenen Tempo entwickeln können. Im Projekt für den Medienmarktführer arbeiteten React-Entwickler Seite an Seite mit dem Backend-Team, sodass neue Funktionen in Daten und Oberfläche stimmig ankamen.
Wie entwickeln Sie ein bestehendes Produkt weiter, statt nur von null zu bauen?
Entgegen dem ersten Eindruck ist das das häufigere Szenario. Ein Verlag hat meist bereits eine Plattform und muss Kompetenzlücken schließen und die Entwicklung beschleunigen, nicht auf einem weißen Blatt anfangen. Dann steigen wir in den bestehenden Code ein, lernen seine Konventionen und ergänzen Menschen genau dort, wo das Team des Kunden ausgelastet ist oder eine Spezialisierung fehlt.
Genau so sieht unser Marktplatzprojekt aus: keine einmalige Einführung, sondern die fortlaufende Entwicklung eines Produkts, in der unser Team Verantwortung für weitere Bereiche übernommen hat und sie gemeinsam mit dem Kunden ausbaut.
Wie legen Sie die Architektur aus, damit eine Medienplattform skaliert?
Eine Medienplattform ist oft ungleichmäßigem Traffic ausgesetzt: ein ruhiger Tag und ein plötzlicher Ausschlag nach einer Kampagne oder einer Veröffentlichung. Deshalb gehen wir von Anfang an davon aus, dass Services unabhängig voneinander skalieren müssen, und legen Suche und Angebotslisten, also die am häufigsten abgefragten Elemente, so aus, dass sie Last aushalten, ohne den Rest des Systems zu beeinträchtigen. Die Aufteilung des Backends in Node.js- und Java-Services ist kein Selbstzweck, sondern genau die Grundlage für diese Art von Skalierung.
Ebenso wichtig: Die Architektur darf die Entwicklung nicht blockieren. Klare API-Verträge, getrennte Module und ein lesbares Datenmodell sorgen dafür, dass das nächste Team oder die nächste Funktion keinen Umbau des Ganzen verlangt.
Wie halten wir die Qualität, während die Plattform wächst?
Bei einem Produkt, das jahrelang lebt und sich ständig ändert, kann Qualität kein Nachgedanke am Ende sein. Wir holen Tester von Anfang an ins Team, neben die Entwickler und nicht erst nach der Übergabe einer Funktion. So fallen Regressionen schnell auf, und jede neue Funktion erreicht die Produktion geprüft statt auf gut Glück.
In der Praxis heißt das: neue Nutzerpfade testen, die kritischen Marktplatzfunktionen kontrollieren (Einstellen, Suche, Kontakt) und Tester, die im selben Sprint mit den Entwicklern arbeiten. Im Projekt für den Medienmarktführer waren Tester fester Teil des Teams, was es erlaubte, die Plattform schnell weiterzuentwickeln, ohne Bestehendes zu zerstören.
Wie schnell kann ein Team in ein Medienplattform-Projekt einsteigen?
Die Geschwindigkeit des Einstiegs entscheidet, ob die Beschleunigung echt ist. Unsere Rekrutierung und Besetzung der Rollen schließt meist in zwei bis drei Wochen ab, und wir stellen das Team passend zum konkreten Projekt zusammen, nicht aus einem fertigen Regal. Als Nearshore-Partner aus Polen arbeiten wir in einer nahen Zeitzone, sodass das Team ohne lange Anlaufzeit an Ihren Code-Reviews, Terminen und Ihrem Sprint-Rhythmus teilnimmt.
Wie machen wir das bei RITS?
Wir machen das als Nearshore-Partner aus Polen, mit echter Erfahrung im Bauen und Weiterentwickeln von Medienplattformen:
- für einen Marktführer im Medien- und Digitalbereich haben wir eine Immobilien-Marktplatzplattform gebaut und entwickeln sie weiter,
- wir haben Node.js-Architekten, Node-, Java- und React-Entwickler sowie Tester in einem geschlossenen Team gestellt,
- wir arbeiten agil und passen Umfang und Tempo an das Budget des Kunden an,
- wir besetzen Rollen meist in zwei bis drei Wochen und stellen die Kompetenzen passend zum Produkt zusammen.
Meist machen wir das als Individualsoftware, gebaut und weiterentwickelt von unserem Team, und dort, wo Kompetenzen schnell aufgestockt werden müssen, als Team-Verstärkung.
Womit fangen Sie beim Bau einer Medien-Anwendung oder -Plattform an?
Starten Sie mit der einen Transaktion, die funktionieren muss, und mit der Frage, welche Daten und welchen Traffic die Plattform tragen soll. Das bestimmt den Umfang der ersten Version, die Backend-Architektur, die Form des Frontends und die Rollen, die Sie brauchen. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie bauen oder entwickeln eine Medien-Anwendung oder -Plattform? Sprechen wir darüber, wir stellen Team und Architektur passend zu Ihrem Produkt zusammen.