the whole system · in seven stages

How templaitemanager works.

A user shows up, signs up, fills out setup, and gets a live-domain site with accounts / auth / community / theatre / booking — all wired up. Then that same site auto-packages into a PWA + a signed APK that submits to Google Play + Apple with a privacy pull. This is the full pipeline, end-to-end, in plain terms.
01

Brain template system Devx

The engine sits on the brain server. Every brand is compiled from ONE shared source of truth — a stack of HTML pages, small reusable components, PHP handlers, and JS handlers. When devx updates any of those pieces, every brand can regenerate to pick the change up.

Pageshome / community / theatre / booking / privacy / etc — the HTML blueprints
Componentsheader / footer / composer / auth-modal / lock — reusable pieces stitched into pages
PHP handlersserver-side endpoints — auth, chat, favs, shares, media, seat-holds
JS handlersclient behaviors — community-handler.js / media-handler.js / theatre bindings

Devx edits any of those → runs a regen → every brand's combined/ output is rebuilt.

02

User fills setup on the platform User

The user lands on the templaitemanager platform, creates an account, and walks through the setup flow: brand name, colors, tagline, category, media style, tier structure, everything. Every answer becomes a field in the brand's config.json.

No code, no engineering — a form.

03

Preview site is printed Devx

The platform pushes the user's setup answers to the brain. The brain runs a regen using the shared template stack + the user's config.json, and prints a preview site at a stable preview URL. User sees their brand come to life instantly.

They keep filling stuff out in the portal — new fields, new tiers, new videos, new features — each save pushes to preview and rerenders. Iterative loop.

04

Domain locked in the portal → submit to sandbox User Devx

Once the user is happy with their preview, they lock a domain in the portal (either one they own or one purchased through templaite). They hit submit. That's the trigger.

The submission pushes the preview build to a sandbox slot on a live server — same regen output, but now on a real box, ready to be assigned a real IP.

05

IP + nginx + full stack wired up ACS · plumbing

ACS assigns an IP to the sandbox slot, points the user's domain at it, and configures nginx to route the domain to that slot. Once the routing is live, every system on the site is wired and functional:

Accountssignup / login / password reset — Airtable-backed
Auth systemsession cookies, protected routes, member-only lobbies
Communitylobbies, chat, favorite colors, tri-color rings, notifications
Theatrevideo queue, per-video lobbies, seat holds, member gates
Booking / Consultcalendar slots, deposits, per-brand rates
Media statslikes, favs, shares, views, per-user engagement history

Devx doesn't touch the plumbing — that's ACS's zone. Devx only ships the template stack that lands on it.

06

PWA installable ASAP → auto-packaged as an app Devx

The moment the domain is live, the site is already installable as a PWA (progressive web app). One tap on iOS "Add to Home Screen" or Android "Install app" and the user has a real installed shell — offline splash, full-screen, custom icon, no browser chrome.

In parallel, devx runs the auto-package step: the same live URL gets wrapped in a Capacitor WebView, signed with the templaite keystore, and emitted as an .aab (Play) and .ipa (Apple). Every brand goes through the exact same build — one pipeline, N outputs.

PWAzero build cost · instant install · updates every page load
Signed AABready for Play Console upload · signed with the fresh templaite keystore
Signed IPAready for App Store Connect · needs a Mac or MacStadium
07

Privacy pulled → ACS reviews → submit to store ACS Devx

The build pipeline pulls the brand's /privacy/ URL and packages it into the store listing (Play + Apple both require it inline).

ACS runs through the live app version — clicks around in the installed shell, verifies branding, engagement, chat, checkout. When it looks right, ACS says go, and devx submits to the stores: Play Console → Internal → Open Beta → Production, and Apple App Store Connect → TestFlight → Review → Live.

After that, every future content change is instant. The WebView loads the live URL. No re-review, no re-upload, no delay. Only when the native shell itself changes (icon, splash, permissions) does a new signed build get pushed.

not just words · read the actual code
Want the actual per-page manifest — which components each page composes, which handler JS files it loads, every /api/ endpoint it calls, and the PHP template backing each one? Devx extracted it straight from the brain template source and rendered it as a browsable matrix.
Open Platform Map →
Rules of the road
Source of truth
One brain template stack. Every brand regens from it. No brand-specific forks.
Devx zone
Templates, components, handlers, regen, build pipeline, keystore, packaging, store submission.
ACS zone
Plumbing — IPs, nginx, domain routing, DNS, dev-account ownership, final approvals.
User zone
Setup form on the portal. Preview iterations. Domain lock. Payment. That's it.
Content updates
Deploy to the brand site → WebView picks it up next page load. No store review needed.
Shell updates
Only for icon, splash, permissions, target SDK. Fresh AAB, 1–3 day Play review.