How the systems fit — one owned stack: the site, the identity and the data all on Cloudflare; Ghost sends the newsletter. The data layer is the asset; the fan portal is the first client that fills it, on the web. Sports data feeds the platform; the platform and portal are instrumented; every interaction lands in a store ShePlayz owns. Two ideas hold it together: the data seam (the contract between any vehicle and the data layer — the portal today, a native app or a personal agent later) and ownership (everything on ShePlayz accounts). No PWA or push in scope for the portal; the native app comes later, for the native-only layer.
Read top-down: sports data comes in from external feeds → renders on the owned Cloudflare site → the fan portal (and later the app) turns viewers into known, instrumented users → every interaction flows into a ShePlayz-owned store. The portal and the site are clients on the same owned data layer, not separate products — and the whole stack (site, identity, data) sits on Cloudflare, with Ghost sending the newsletter.
Two distinct data streams feed the platform, and they map to two different league lists — a distinction worth being precise about:
Fixtures, results, standings — from TheSportsDB, API-Football, ESPN. Chosen because these leagues have clean free coverage. A normalisation layer presents all three through one internal shape — this layer is owned outright, not rented from a commodity vendor.
News and coverage via AP, Reuters, PA Media through the Hermes pipeline. These are the licensed editorial leagues — the content spine. Data-feed coverage for them (and for MENA leagues) is thinner, which is why the structured widgets lead with the WNBA/WSL/NWSL set.
Live tier vs. deferred tier. Fixtures, results and standings are the built tier. Live / in-progress scores are the expensive tier — deliberately deferred to v3, gated on live-data cost falling below 15% of run-rate revenue. The MVP runs on scheduled and post-match data, not live.
The site is a custom front-end on Cloudflare Pages — the Signal4i pattern — not a CMS theme. Hermes publishes wire-fed news straight to it, so Ghost sits out of the news path. Ghost is scoped to what it's best at: the newsletter and membership list — 0% subscription cut, strong deliverability, a fully owned and exportable list — with the newsletter archive rendered as pages on the Cloudflare site. Two systems, each doing one job, both on ShePlayz ground.
Fast edge hosting, full technical-SEO / GEO control, and the interactive pieces (fixtures, feed, the portal) native to the front-end instead of theme-injected. Content + assets migrate off Wix onto it.
Search Console baseline before the move (gates the date), a full ~400-post 301 redirect map, and post-migration verification — no dark window.
Kept to the list + sending engine: owned, exportable subscribers and The Rundown. Not the site, not the identity system — the archive renders on-site, and members sync from the owned identity layer.
Why the split: Bubs isn't a heavy publisher, so a single Ghost CMS bought little — while a custom Cloudflare front-end buys SEO/GEO control, edge speed, and native interactive surfaces that the portal needs. No PWA or service worker in scope — the portal is a responsive web app; the native app comes later for the things only native gives.
Every owned surface — the site, the newsletter, and the portal (and later the app) — is instrumented so every interaction becomes a stored, structured signal in a store ShePlayz owns, on Cloudflare (D1 for the event stream and follow graph, R2 for media). This is the compounding asset; it's built native to the surfaces, not bolted on, which is why the schema — and the identity model it hangs on — has to be right before engineering.
| Component | What it is |
|---|---|
| Owned identity | A passwordless magic-link sign-in issued on Cloudflare Workers — ShePlayz is the system of record for a person (email + follows + consent + behaviour), no passwords stored. The same account is synced to Ghost as the newsletter list, so the newsletter and the portal are one owned account; the native app later joins the same identity. Ghost is not the login. To design. |
| Event schema | Named events, properties, consent flags. Starter set exists (widget views, sessions by sport/region/language, newsletter clicks); the full taxonomy — athlete / team / competition / sport as first-class entities with the edges between them — is the one irreversible pre-engineering decision still to sign off. |
| Capture pipeline | Events from all owned surfaces (site, portal, newsletter) flow into D1 reliably, with validation and no PII beyond agreed. PDPL (UAE/Saudi) residency designed in from day one. |
| Owned store | Provisioned under ShePlayz's own Cloudflare account — not build-partner infrastructure — holding the event stream and follow graph, exportable at any time. |
| Reporting view | Volumes and top cuts by sport / region / language / surface — enough to "see the audience." The full intelligence product is a later, separate build. |
The data-compounding path the whole layer serves: implicit signal → declared preference → live behaviour → a saleable intelligence product. You can only analyse what you captured — which is why instrumentation can't be retrofitted.
A vehicle is whatever turns a viewer into a known, instrumented user. The v1 vehicle is the fan portal — a responsive web app on the Cloudflare front-end, behind one sign-in. It reads fixtures, news and follows from the Workers API and writes events back — the same owned data layer a native app or a personal agent would later read from. The native app isn't cancelled; it's the earned upgrade, built once the portal proves the feature set.
Follows, personalised feed, fixtures, and email / add-to-calendar reminders — behind one passwordless sign-in. Arabic-first, instrumented from the first session. Built entirely on the owned Cloudflare stack (Pages + Workers + D1), so there's no offshore seam and no store review to clear — it ships in weeks and iterates in place. No PWA, no push.
React Native / Expo, resourced from the India bench, reading the same data layer and identity. It adds only what the web genuinely can't: real device push, offline, and a home-screen presence. Chosen for RN because it shares a language with the web stack; the platform (iOS vs Android) is decided against real audience share, when the data has earned the build.
v1 scope: follows + personalised feed + fixtures + email/calendar reminders, on the web, instrumented, one owned store. Follow-your-athlete is pulled forward to v1 (cheap on the web); live in-progress scores stay deferred. The current ~20-user native app is parked; the portal is the first real build.
Every vehicle meets the data layer at a defined contract. For the v1 portal this seam is internal — front-end, API, identity and store all sit on one owned Cloudflare stack, our side, no time-zone gap — which is a large part of why the portal is a weeks-not-quarters build. The seam becomes the critical, load-bearing interface when the native app is built later off the India bench: an offshore pod builds exactly what's specified, and a vague seam becomes assumptions discovered at integration. The payoff of nailing the schema and API contract for the portal now is that the later app build inherits a proven contract instead of designing one across a time-zone gap.
The named events + properties every vehicle fires. Defined by our side; the same schema serves the portal and, later, the app.
Every endpoint a vehicle reads/writes — fixtures, news, follows, event ingest. Written for the portal; reused by the app.
How an account ties to email + behaviour — the owned magic-link record. The one piece every surface must agree on up front.
Scheduled Workers that send a fixture reminder by email + an add-to-calendar link. Server-side; no device push involved.
An integration owner on our side protects this seam day-to-day. It's light for the portal; when the offshore app build starts, this role is the difference between fast and frustrating.
The architecture has one non-negotiable running through every layer: ShePlayz owns the result outright. The widget code, the normalisation layer, the owned identity system, the capture pipeline, the data store and its contents, the Cloudflare site, the Ghost list, and all configuration are permanent ShePlayz property — delivered onto ShePlayz's own Cloudflare and Ghost accounts. Nothing critical lives on build-partner infrastructure, and the build partner holds no residual rights. The data-ownership confirmation is the one clause to make explicit in the engagement. That's the whole thesis in the architecture: own your source, own your intelligence.