Shared system core
THAILAND VLOGGERS · IN-HOUSE PRODUCT BY BTECH SOLUTIONS
Thailand Vloggers.Two surfaces, one ecosystem.
A public site built to be found and a closed area where the work happens — one shared data foundation, two deliberately separated delivery paths.
The public surface is prerendered and served statically. Creator, partner, and editorial areas sit behind it as a dynamic application on a Django REST interface. That pattern is transferable — built on our own product and in operation.
- Public surface live
- Product area closed
- Built entirely in-house
BTECHOSconnected core
- SSG site
- Creators
- Partners
- Editorial
- API
Why two surfaces instead of one
Visibility and workspace pull in opposite directions.
Anything meant to be found has to exist in the source without a login, without a wait, and without depending on JavaScript. Anything that gets maintained, approved, and moderated needs roles, states, and authentication. Forcing both into one application costs either visibility or control.
Today scattered across
- Content scattered across channels
- Profiles with no way to maintain them
- Editorial work in spreadsheets
- Media without an approval step
- No shared source of truth
Thailand Vloggers separates delivery from work, and keeps both on the same data model.
The platform core
Modules that exist in the code, not on a wish list.
The platform is built modularly: separate feature directories in the frontend, separate applications in the backend. Modules are added as they are needed. Anything planned but not yet built is deliberately kept out of this list and named in the questions at the end of the page.
Public discovery surface
Discover, creator profiles, videos, guides, and map as prerendered pages — the surface search engines and language models actually read.
Regions, places, and categories
Regions, locations, categories, attractions, restaurants, and nightlife as their own entry pages instead of filters on a single list.
Creator area
Dashboard, profile editor, social links, media upload, an own creator website, guides, map locations, change history, and security settings — behind the login.
Partner area
Partner home, location editor, map location, media, analytics, and settings as a role space of its own next to the creator area.
Operations and editorial
Lists and editors for creators, videos, guides, regions, categories, and places, plus claim review, change approval, and pending items.
Moderation and audit trail
Separate moderation for content, media, and partners, plus per-creator legal texts and an audit log — decisions stay readable after the fact.
Backend and interface
Django 5 with Django REST Framework, split into separate applications for accounts, community, content, content sync, creators, locations, media, moderation, and notifications.
Submissions and contact
Publicly implemented and not to be confused with the planned community app: contact request, channel suggestion, photo contribution, issue report, and profile claim, each with its own record in the backend.
BTECH BUSINESS SUITE
Four products. One shared core.
Each product keeps its visible status: approved pilot or early beta, without a blanket availability claim.
BTech OS
The modular operating layer connects website, CRM, bookings, projects, documents, billing, content and analytics on one controllable data foundation.
The product core is demonstrable and is being expanded through selected pilot implementations. Scope and interfaces are not final yet. View productBTech Growth
A multi-tenant platform foundation for courses, programmes, customer onboarding, memberships and internal learning worlds under your own brand.
The white-label platform is in early beta. The product core and demo are available; real content, operations and integrations are finalised per pilot project. View productSocial Media Pipeline
Planning, production, approvals, channel variants, publishing and analytics are organised as a connected BTech OS module.
The pipeline is being developed as an early-beta BTech OS module. Channel adapters and automation rules are enabled per pilot operation. View productShowcase Module
A modular BTech OS component for vehicles, services and portfolios with strong media, variants, facts, comparison and direct conversion.
The module is in early beta. The automotive demonstration shows the product approach; data models and industry variants are being extended with pilot partners. View product
System architecture
The order in which this platform was built.
The starting point was not a feature list but the question of what gets delivered publicly and what belongs behind a login. That separation then decides rendering, roles, and data paths.
- 01
Separate the surfaces
Decide which content must be reachable publicly and without a login, and which processes belong in a closed area by default.
- 02
Data model and roles
Model creators, places, media, contributions, and states once, so that editorial, partners, and moderation later work on the same records.
- 03
Deliver the public side statically
The discovery surface ships prerendered: content is in the source, independent of whether an application responds.
- 04
Workspaces behind the login
Creator, partner, and editorial areas run as a dynamic application against the REST interface, with approval, history, and moderation as explicit steps.
- 05
Extend as needed
Further modules arrive when a workflow needs them, not because they are on a list. Anything not yet built is labelled as planned.
One core, several deliveries
The same data, delivered in different ways.
Creators, places, media, approvals, and states live once in the backend. What is built on top differs in rendering, access, and purpose, not in the data foundation.
Delivered surfaces
- 01Public discovery site
- 02Creator workspace
- 03Partner workspace
- 04Editorial and moderation
- 05Submission path
- 06REST interface
One data model. Separate role spaces. Two deliberately different delivery paths.
What this pattern is good for
Transferable to anything that is a directory and an editorial operation at once.
- 01
Directories and networks
Platforms where profiles need to be found and where profile owners maintain their own data, with claims, approval, and history.
Discovery - 02
Regional and topical portals
Offerings whose visibility comes from regions, categories, and places, and which still need a maintained editorial layer behind them.
Topic clusters - 03
Operations with partner workflows
Organizations that accept content from outside and must review it before publishing, including moderation, roles, and an audit trail.
Moderated operations
Build principles
Four decisions this platform rests on.
Static where it must be found
The public surface ships prerendered. Content is in the source, not only after JavaScript has run.
Closed where work happens
Creator, partner, and editorial areas sit behind the login. The product area is not openly reachable from outside.
Built modularly
Separate feature directories and separate backend applications. Modules are added as needed, which is not the same as a switch per feature.
Traceable, not silent
Changes to profiles, media, and content run through approvals and leave history and an audit log instead of a silent overwrite.
Who this page is for
For operators who need a directory and an editorial operation at the same time.
- Operators of creator and provider directories
- Travel, regional, and topical portals
- Organizations with partner and role areas
- Providers with moderation and approval duties
- Teams that want visibility and workspace separated
Questions about Thailand Vloggers
What exists, what is planned, and what this page does not claim.
An in-house product. The public site, the application, and the backend all come from the same in-house development. This page is therefore not a reference for an external client but the description of a system that was built and is operated here.
No. The public site is freely reachable, the product area is a closed area: a request from outside is refused and nothing is served there. What the area contains is listed in the module cards above; it can only be shown in a guided conversation.
No. The community part is explicitly marked as "in planning" in the code and shows the product idea, not a released app. The four items carry their own status there: profile and watchlist — planned; thematic spaces — planned; contributions with guardrails — later; a strictly bounded player — needs review. The intended order is web, then Android, then iOS. What works publicly today is the submission path: contact, channel suggestion, photo contribution, issue report, and profile claim.
Separate feature directories in the frontend, separate applications in the backend — and modules are added as needed. What it explicitly does not mean is a switch per feature: there is no central registry that would turn individual features on and off at runtime, and this page therefore never claims one.
This page names no prices, no packages, and no budget thresholds — a number without a defined scope would be a guess. First we clarify which surfaces, roles, and workflows are actually needed; the offer follows from that conversation.
Not as a copy. What transfers is the pattern: separating public delivery from the closed workspace, distinct role spaces, approval with history, and one backend serving both sides. Which of those modules a specific project actually needs is decided by the workflow that has to run.
The next useful step
Your directory, your editorial team, your roles.
In a structured conversation we clarify which surfaces belong in public, which belong behind a login, which roles genuinely exist, and the smallest scope at which the system holds up in operation.