The right tool
for each layer.
Locapublish is built on four distinct layers. Each tool does what it is actually designed for — no over-engineering, no monolithic plugins carrying weight they weren’t built for.
Stack summary
Each layer has a single, clear responsibility. No layer bleeds into another’s domain.
| Tool | Responsibility | Role |
|---|---|---|
| WordPress | Marketing site, landing pages, content, publisher info pages, SEO, blog | Website |
| Supabase | User auth, demand signal tables, publisher dashboards, RLS security, API | App + Database |
| Stripe | Card storage (Setup Intents), deposit charges, reservations, refunds, Customer IDs | Payments |
| WooCommerce | PDF language packs, physical add-ons, downloadable files, localized preorders — if needed later | Product sales (optional) |
WordPress — the website
WordPress is the public-facing content layer. It handles everything that doesn’t require a user account or a database transaction.
WordPress does what it is built for: presenting content to the public. Landing pages, the Games catalogue view, publisher information pages, the Market Signal Audit page, pricing, and this documentation. SEO-optimised, fast, and easy to update without a developer.
User login, demand signals, voting, dashboards, publisher data, card verification, deposits, or any transactional logic. These all live in Supabase and Stripe — not in WordPress or its plugins.
Supabase — the application
Supabase is the core of Locapublish. Everything that requires a user, a record, a permission check, or a live data query runs through Supabase.
Supabase provides the full application backend: authentication, row-level security, API access, and the database tables that power every feature. The demand signal system, publisher dashboards, partner profiles, and language market data all live here.
users → auth.users + profiles
titles → game/title records, publisher_id, status
demand_signals → user_id, title_id, language_code, signal_type
languages → title_id, language_name, status, signal_count
publishers → name, contact, stripe_customer_id
comms_optin → user_id, title_id, opted_in, opted_in_at
Stripe — payments
All card data, deposits, and financial transactions go through Stripe. Locapublish never stores card details itself.
Stripe handles the financial layer of demand validation. A user who wants to signal “verified” intent adds a card via a Stripe Setup Intent — no charge is made yet. If the localization is greenlit, a deposit or payment can be captured against the stored payment method. Refunds are handled by Stripe if the project doesn’t proceed.
Locapublish stores only the Stripe Customer ID in Supabase. Card numbers, CVVs, expiry dates — none of this ever touches your database. All sensitive card data lives in Stripe’s PCI-compliant vault. This is non-negotiable.
1. stripe.setupIntents.create() → collect card, no charge
2. stripe.customers.create() → store customer_id in Supabase
3. supabase: signal_type = ‘card-verified’
4. stripe.paymentIntents.create() → capture deposit when greenlit
5. stripe.refunds.create() → refund if project cancelled
WooCommerce — later, maybe
WooCommerce is not part of the core Locapublish system. It becomes relevant only if you add a standard product catalogue — not for the demand-signal or reservation flow.
The demand signal, card verification, deposit, and reservation system should not be built on WooCommerce. WooCommerce is designed for cart-based product sales — it is the wrong abstraction for what Locapublish does. Trying to force voting, intent signals, and conditional deposits through WooCommerce order flows will create significant technical debt and brittle UX.
When WooCommerce makes sense
If Locapublish adds a product layer — selling digital or physical goods directly — WooCommerce is a reasonable choice. These are standard transactional products, not demand signals:
Technical direction — what to build and what not to
✗ DO NOT store card details, CVVs, or payment credentials in your own database.
✗ DO NOT use WordPress user tables or session logic for demand signal auth.
✗ DO NOT build publisher dashboards inside WordPress admin.
✓ USE WordPress only as the marketing and content layer.
✓ USE Supabase Auth for all user registration and login.
✓ USE Supabase tables + RLS for demand signals, dashboards, and publisher data.
✓ USE Stripe Setup Intents for card verification — no charge at time of signal.
✓ USE Stripe Payment Intents to capture deposits only when a localization is greenlit.
✓ CONSIDER WooCommerce later, only for ordinary product sales — not for the core demand-validation flow.