<style> .film__track { height: auto !important; } .film__stage { position: static !important; height: auto !important; /* Ohne diese Zeile ist der Rückfall LEER: container-type: size bemisst die Bühne nicht mehr nach ihrem Inhalt, und overflow: hidden schneidet alles weg. */ container-type: normal !important; } .film__poster { position: absolute !important; } .film__content [data-film-anchor] { position: static !important; transform: none !important; opacity: 1 !important; margin: 2.5rem clamp(1rem, 5vw, 4rem) !important; max-width: 34rem; } </style>

THAILAND VLOGGERS · EIGENPRODUKT VON BTECH SOLUTIONS

Thailand Vloggers.Zwei Flächen, ein Ökosystem.

Eine öffentliche Seite, die gefunden werden soll, und ein geschlossener Bereich, in dem gearbeitet wird – dieselbe Datenbasis, zwei bewusst getrennte Auslieferungswege.

Die öffentliche Fläche wird statisch vorgerendert ausgeliefert. Creator-, Partner- und Redaktionsbereiche liegen dahinter als dynamische Anwendung auf einer Django-REST-Schnittstelle. Genau dieses Muster ist übertragbar – gebaut am eigenen Produkt und im Betrieb.

  • Öffentliche Fläche live
  • Produktbereich geschlossen
  • Vollständige Eigenentwicklung
THAILAND VLOGGERS PLATFORM SYSTEMBEREIT
BTECHOSverbundener Kern
  1. SSG-Seite
  2. Creator
  3. Partner
  4. Redaktion
  5. API

Warum zwei Flächen und nicht eine

Sichtbarkeit und Arbeitsfläche haben gegensätzliche Anforderungen.

Was gefunden werden soll, muss ohne Anmeldung, ohne Wartezeit und ohne JavaScript-Abhängigkeit im Quelltext stehen. Was gepflegt, freigegeben und moderiert wird, braucht Rollen, Zustände und eine Anmeldung. Beides in eine einzige Anwendung zu zwingen, kostet entweder Sichtbarkeit oder Kontrolle.

Heute verteilt auf

  • Inhalte über Kanäle verstreut
  • Profile ohne Pflegeweg
  • Redaktion in Tabellen
  • Medien ohne Freigabeschritt
  • Kein gemeinsamer Datenstand

Thailand Vloggers trennt die Auslieferung von der Arbeit – und hält beide auf demselben Datenmodell.

Der Plattformkern

Module, die im Code stehen – nicht auf einer Wunschliste.

Die Plattform ist modular aufgebaut: getrennte Feature-Verzeichnisse im Frontend, getrennte Anwendungen im Backend. Module kommen nach Bedarf dazu. Was geplant, aber noch nicht gebaut ist, steht bewusst nicht in dieser Liste, sondern in den Fragen am Seitenende.

  • SSG · öffentlich

    Öffentliche Entdeckungsfläche

    Discover, Creator-Profile, Videos, Guides und Karte als vorgerenderte Seiten – die Fläche, die Suchmaschinen und Sprachmodelle tatsächlich lesen.

  • Topic-Struktur

    Regionen, Orte und Kategorien

    Regionen, Locations, Kategorien, Attraktionen, Restaurants und Nightlife als eigene Einstiegsseiten statt als Filter auf einer einzigen Liste.

  • Geschlossener Bereich

    Creator-Bereich

    Dashboard, Profil-Editor, Social-Links, Medien-Upload, eigene Creator-Website, Guides, Kartenorte, Änderungshistorie und Sicherheitseinstellungen – hinter der Anmeldung.

  • Geschlossener Bereich

    Partner-Bereich

    Partner-Startseite, Location-Editor, Kartenort, Medien, Auswertungen und Einstellungen als eigener Rollenraum neben dem Creator-Bereich.

  • Redaktionsschicht

    Betrieb und Redaktion

    Listen und Editoren für Creator, Videos, Guides, Regionen, Kategorien und Orte, dazu Claim-Prüfung, Änderungsfreigabe und offene Vorgänge.

  • Governance

    Moderation und Nachweis

    Getrennte Moderation für Inhalte, Medien und Partner, dazu Rechtstexte je Creator und ein Auditlog – Entscheidungen bleiben nachlesbar.

  • Django 5 · DRF

    Backend und Schnittstelle

    Django 5 mit Django REST Framework, aufgeteilt in eigene Anwendungen für Konten, Community, Inhalte, Content-Sync, Creator, Orte, Medien, Moderation und Benachrichtigungen.

  • Implementiert

    Einreichung und Kontakt

    Öffentlich implementiert und nicht zu verwechseln mit der geplanten Community-App: Kontaktanfrage, Kanalvorschlag, Fotobeitrag, Problemmeldung und Profilanspruch, jeweils mit eigenem Datensatz im Backend.

BTECH BUSINESS SUITE

Vier Produkte. Ein gemeinsamer Kern.

Der Status jedes Produkts bleibt sichtbar: freigegebener Pilot beziehungsweise frühe Beta – kein pauschaler Verfügbarkeitsclaim.

  • Hauseigene Entwicklung · Frühe Beta

    BTech OS

    Die modulare Betriebsschicht verbindet Website, CRM, Termine, Projekte, Dokumente, Abrechnung, Content und Analytics auf einer kontrollierbaren Datenbasis.

    Der Produktkern ist demonstrierbar und wird kontrolliert mit ausgewählten Pilotanwendungen erweitert. Funktionsumfang und Schnittstellen sind noch nicht final. Produkt ansehen
  • Hauseigene Entwicklung · Frühe Beta

    BTech Growth

    Mandantenfähige Plattformbasis für Kurse, Programme, Kunden-Onboarding, Memberships und interne Lernwelten unter eigener Marke.

    Die White-Label-Plattform befindet sich in einer frühen Beta. Der Produktkern und die Demo sind vorhanden; reale Inhalte, Betriebsprozesse und Integrationen werden je Pilotprojekt finalisiert. Produkt ansehen
  • Hauseigene Entwicklung · Frühe Beta

    Social Media Pipeline

    Planung, Produktion, Freigaben, kanalbezogene Varianten, Veröffentlichung und Auswertung werden als verbundenes BTech-OS-Modul organisiert.

    Die Pipeline wird als frühes Beta-Modul innerhalb von BTech OS entwickelt. Kanaladapter und Automationsregeln werden kontrolliert pro Pilotbetrieb freigeschaltet. Produkt ansehen
  • Hauseigene Entwicklung · Frühe Beta

    Showcase-Modul

    Ein modularer BTech-OS-Baustein für Fahrzeuge, Leistungen und Portfolios mit starken Medien, Varianten, Fakten, Vergleich und direkter Conversion.

    Das Modul befindet sich in früher Beta. Die Kfz-Demonstration zeigt den Produktansatz; Datenmodelle und branchenspezifische Varianten werden mit Pilotpartnern erweitert. Produkt ansehen

Systemaufbau

In welcher Reihenfolge diese Plattform entstanden ist.

Am Anfang stand nicht die Funktionsliste, sondern die Frage, was öffentlich ausgeliefert wird und was hinter eine Anmeldung gehört. Diese Trennung entscheidet danach über Rendering, Rollen und Datenwege.

  1. 01

    Flächen trennen

    Festlegen, welche Inhalte öffentlich und ohne Anmeldung erreichbar sein müssen – und welche Vorgänge grundsätzlich in einen geschlossenen Bereich gehören.

  2. 02

    Datenmodell und Rollen

    Creator, Orte, Medien, Beiträge und Zustände einmal sauber modellieren, damit Redaktion, Partner und Moderation später auf denselben Datensätzen arbeiten.

  3. 03

    Öffentlich statisch ausliefern

    Die Entdeckungsfläche wird vorgerendert ausgeliefert: Inhalte stehen im Quelltext, unabhängig davon, ob eine Anwendung antwortet.

  4. 04

    Arbeitsflächen hinter die Anmeldung

    Creator-, Partner- und Redaktionsbereiche laufen als dynamische Anwendung gegen die REST-Schnittstelle – mit Freigabe, Historie und Moderation als eigenen Schritten.

  5. 05

    Nach Bedarf erweitern

    Weitere Module kommen dazu, wenn ein Ablauf sie braucht – nicht, weil sie auf einer Liste stehen. Was noch nicht gebaut ist, wird als geplant ausgewiesen.

Ein Kern, mehrere Auslieferungen

Dieselben Daten, unterschiedlich ausgeliefert.

Creator, Orte, Medien, Freigaben und Zustände liegen einmal im Backend. Was daraus entsteht, unterscheidet sich in Rendering, Zugriff und Zweck – nicht in der Datenbasis.

Gemeinsamer Systemkern

Thailand Vloggers

Ausgelieferte Flächen

  • 01Öffentliche Entdeckungsseite
  • 02Creator-Arbeitsfläche
  • 03Partner-Arbeitsfläche
  • 04Redaktion und Moderation
  • 05Einreichungsstrecke
  • 06REST-Schnittstelle

Ein Datenmodell. Getrennte Rollenräume. Zwei bewusst verschiedene Auslieferungswege.

Wofür dieses Muster taugt

Übertragbar auf alles, was Verzeichnis und Redaktionsbetrieb zugleich ist.

  • 01

    Verzeichnisse und Netzwerke

    Plattformen, auf denen Profile gefunden werden sollen und die Profilinhaber ihre Daten selbst pflegen – mit Anspruch, Freigabe und Historie.

    Discovery
  • 02

    Regional- und Themenportale

    Angebote, deren Sichtbarkeit über Regionen, Kategorien und Orte entsteht und die trotzdem eine gepflegte Redaktion dahinter brauchen.

    Topic-Cluster
  • 03

    Betriebe mit Partnerablauf

    Organisationen, die Inhalte von aussen annehmen und vor der Veröffentlichung prüfen müssen – Moderation, Rollen und Nachweis inbegriffen.

    Moderationsbetrieb

Bauprinzipien

Vier Entscheidungen, die diese Plattform tragen.

  • Statisch, was gefunden werden soll

    Die öffentliche Fläche wird vorgerendert ausgeliefert. Inhalte stehen im Quelltext, nicht erst nach dem Ausführen von JavaScript.

  • Geschlossen, was Arbeit ist

    Creator-, Partner- und Redaktionsbereiche liegen hinter der Anmeldung. Der Produktbereich ist von aussen nicht offen erreichbar.

  • Modular aufgebaut

    Getrennte Feature-Verzeichnisse und getrennte Backend-Anwendungen. Module kommen nach Bedarf dazu – das ist etwas anderes als ein Schalter je Funktion.

  • Nachvollziehbar statt still

    Änderungen an Profilen, Medien und Inhalten laufen über Freigaben und hinterlassen Historie und Auditlog statt einer stillen Überschreibung.

Für wen diese Seite gedacht ist

Für Betreiber, die ein Verzeichnis und einen Redaktionsbetrieb zugleich brauchen.

  • Betreiber von Creator- und Anbieterverzeichnissen
  • Reise-, Regional- und Themenportale
  • Organisationen mit Partner- und Rollenbereichen
  • Anbieter mit Moderations- und Freigabepflicht
  • Teams, die Sichtbarkeit und Arbeitsfläche trennen wollen

Fragen zu Thailand Vloggers

Was existiert, was geplant ist – und was diese Seite nicht behauptet.

Ein Eigenprodukt. Öffentliche Seite, Anwendung und Backend stammen aus derselben Entwicklung im eigenen Haus. Diese Seite ist deshalb kein Referenzbeleg für eine fremde Auftraggeberin, sondern die Beschreibung eines Systems, das hier gebaut wurde und betrieben wird.

Nein. Die öffentliche Seite ist frei erreichbar, der Produktbereich ist ein geschlossener Bereich: eine Anfrage von aussen wird abgewiesen, ausgeliefert wird dort nichts. Was der Bereich enthält, steht oben in den Modulkarten; ansehen lässt er sich nur im begleiteten Gespräch.

Nein. Der Community-Teil ist im Code ausdrücklich als „In Planung" gekennzeichnet und zeigt die Produktidee, keine bereits veröffentlichte App. Die vier Punkte tragen dort ihren eigenen Status: Profil und Merkliste – vorgesehen; thematische Räume – vorgesehen; Beiträge mit Leitplanken – später; ein klar begrenzter Player – Prüfung nötig. Die geplante Reihenfolge ist Web, dann Android, dann iOS. Was heute öffentlich funktioniert, ist die Einreichungsstrecke: Kontakt, Kanalvorschlag, Fotobeitrag, Problemmeldung und Profilanspruch.

Getrennte Feature-Verzeichnisse im Frontend, getrennte Anwendungen im Backend – und Module kommen nach Bedarf dazu. Ausdrücklich nicht gemeint ist ein Schalter je Funktion: ein zentrales Register, über das sich einzelne Funktionen im laufenden Betrieb an- und abschalten liessen, existiert nicht, und diese Seite behauptet das deshalb nirgends.

Diese Seite nennt keine Preise, keine Pakete und keine Budgetschwellen – eine Zahl ohne festgelegten Umfang wäre geraten. Zuerst wird geklärt, welche Flächen, Rollen und Abläufe wirklich gebraucht werden; das Angebot folgt danach aus dem Gespräch.

Nicht als Kopie. Übertragbar ist das Muster: die Trennung von öffentlicher Auslieferung und geschlossener Arbeitsfläche, getrennte Rollenräume, Freigabe mit Historie und ein Backend, das beide Seiten bedient. Welche Module in einem konkreten Projekt entstehen, entscheidet der Ablauf, der wirklich laufen muss.

Der nächste sinnvolle Schritt

Ihr Verzeichnis, Ihre Redaktion, Ihre Rollen.

In einem strukturierten Gespräch klären wir, welche Flächen öffentlich gehören, welche hinter die Anmeldung, welche Rollen es wirklich gibt und mit welchem kleinsten Umfang das System im Betrieb trägt.

Projektanfrage