Skip to content
BCDIANCO
Motion

Shinjiru WellnessPhilippines — Remote

Shinjiru Wellness — 5 Product Funnels, WebCake to Cloudflare

5 product funnels, rebuilt standalone on Cloudflare Pages

Web DevelopmentE-CommerceOrder-Ops Automation
Shinjiru Wellness
5

Live product funnelsCalmara · Cravelle · GIS · Lunea · Red Lava

−97%

Bundle-pack art payload10.6MB → 0.34MB across 12 files

Sheets + CAPI

Order pipelineApps Script · Pancake POS · server-side Meta

Context

Shinjiru Wellness is a Philippine wellness brand running five SKUs, each with a distinct functional job: Gut In Shape for gut health, Cravelle for cravings, Lunea for sleep, Calmara for stress, and Red Lava — the newest launch — for slimming and skin. The engagement was never just "build landing pages" — it was build the pages and wire them into the order pipeline that PH e-commerce actually runs on: Facebook Messenger commerce, Google Sheets as the source of truth, and a POS system pulling orders out of the same data.

I built the original four on WebCake, a hosted PH page builder. WebCake's clean-v3 architecture (released May 2026, mid-engagement) opened four global injection slots — Before Head, Before Body, Custom CSS, Custom JavaScript — which let the build share styling and interactivity across every page instead of inlining everything into each Custom HTML block. That platform shift dropped per-page payload roughly 60% and carried the line through launch.

Then I rebuilt the whole line as standalone sites on Cloudflare Pages. Not because WebCake failed — it did its job — but because a hosted page builder caps how far you can take a funnel. Every improvement I wanted next lived on the other side of that ceiling: real security headers, a server-side order endpoint, aggressively optimized assets, deploys measured in seconds, and a codebase an AI agent can actually read and edit. Red Lava was built standalone from day one and never touched WebCake at all.

The Challenge

Five problems stacked on top of each other, and the work was solving all five without letting any of them turn into a bottleneck for the others.

  • One design system, five distinct products. Each SKU has its own color territory — navy for Gut In Shape, cream for Cravelle, lilac for Lunea, deep purple for Calmara, molten red for Red Lava — but the layout, type scale, and component vocabulary all had to read as one product line. The risk was making five near-identical pages with a swapped accent color; the goal was five pages that felt like siblings without feeling like duplicates.
  • Mobile-first because that's where PH e-commerce lives. Most traffic to a Philippine wellness brand arrives on a phone, often on a cellular connection. The page weight budget and the breakpoint strategy both started from "what works on a 5-inch screen on 4G" and worked outward. WebCake's mobile preview also breaks @media queries — those fire at the iframe viewport rather than the displayed canvas — which forced a different responsive strategy.
  • A real order pipeline, not just a form. Philippine SMB e-commerce runs through Facebook Messenger, not a hosted checkout. The order CTA had to route the customer into Messenger where a chatbot (Botcake) collects and confirms the order, then the order data had to flow into a backend the operator could actually use — Google Sheets — without manual copy-paste.
  • POS and attribution from day one. Pancake POS pulls orders for fulfillment, Meta Pixel attributes conversions back to the ad spend, and both needed to be wired up at launch — not bolted on after the pages were "done."
  • A page builder you eventually outgrow. WebCake got the line launched fast, but a hosted builder owns the response: you don't control headers, you can't run server-side code, you can't optimize what the CDN serves, and every update means repasting HTML into someone else's editor. Once the funnels were earning, the ceiling stopped being theoretical and started costing speed, security, and integration room.

Approach

The order of decisions mattered more than the decisions themselves.

  1. Globals first, per-page HTML thin. Once WebCake shipped the four injection slots, the architecture flipped: shared CSS, shared JS, shared <head> markup all live in global slots. Each product page's Custom HTML block is just the per-product content scaffold wrapped in <div class="shj-page" data-product="...">. The data attribute drives per-product theming entirely from the global CSS. One global edit propagates to all four pages.
  2. Container queries, not viewport queries. Because WebCake's mobile preview misreports @media width, the responsive system is built on @container shj (max-width: ...) against an inline-size container scoped to .shj-page. That sidesteps the preview bug and behaves correctly in the editor, on desktop, and on real phones.
  3. Order flow routed to Messenger commerce. The product-page order CTA opens a WebCake modal (custom JS) that collects name + phone + email + address + product/bundle selection. On submit, the customer is routed to the Shinjiru Facebook page where Botcake confirms the order conversationally — a familiar pattern for PH buyers, and a friction reduction vs. unfamiliar checkout flows.
  4. Apps Script as the order pipeline glue. Order confirmations arrive in Gmail. A Google Apps Script triggers on inbox events, parses the order, and appends rows to the canonical orders Google Sheet. Pancake POS pulls from the same data source for fulfillment. Meta Pixel fires on the order CTA so paid-ad attribution lines up with the actual conversion event.
  5. Conversion stack built in JS, not faked in CSS. Once Custom JS was available globally, the urgency countdown, FAB show-after-hero behavior, modal auto-bundle-select, scroll-triggered reveals, sheen drift, and per-product theme switching all become real interactive elements instead of CSS hacks.
  6. Then take the ceiling off — rebuild standalone on Cloudflare Pages. Each product became a self-contained site in a git repo: one index.html, its own bundled assets, its own subdomain. That single move unlocked everything the builder couldn't give — real security headers, a server-side order endpoint, assets I control and can compress, deploys in seconds instead of a copy-paste ritual, and a plain-file codebase an AI agent can read and edit directly. Same funnel, same conversion stack, no landlord.

What I Built

The five landing pages. Each ships with the same conversion-stack components, themed per product:

  • Hero with click-to-play founder/testimonial video and tap-to-unmute overlay
  • Vertical testimonial reel in the page's color territory
  • Facebook-style community comments — four Tagalog cards per product
  • FDA notification card — full document, click to enlarge on mobile
  • Trivia / myth section ("Mga bagay na hindi mo alam")
  • Ingredient deep-dive with float + shape-outside cards
  • Comparative positioning panel framing the product as a safer alternative (without naming competitors)
  • Pricing tile with strikethrough original, % saved badge, and the locked promo price
  • 30-day money-back guarantee block with oversized confident typography
  • 5-minute urgency countdown + live stock counter above the pricing block
  • Floating "Order now" CTA that appears once the customer scrolls past the hero
  • Order modal — name / phone / email / address / reason, auto-selects the bundle the customer clicked
  • 60-day ritual closer as the last section before the footer

The shared globals. Site-wide CSS handles typography, color territories, animations (scroll reveal, sheen drift, gradient drift, breathing rings, mascot blink, FAB pulse, button shimmer), and the responsive container-query system. Site-wide JS handles modal open/close + form state, the urgency countdown, FAB show-on-scroll, the per-product theme switcher, and Meta Pixel event firing.

The standalone rebuild. What the move to Cloudflare Pages actually bought:

  • Security headers the builder never allowed. Every site ships a _headers file: a full Content-Security-Policy pinned to the exact origins the funnel uses (Facebook, Apps Script, Google Fonts), plus frame-ancestors 'none', X-Frame-Options: DENY, nosniff, HSTS, a strict referrer policy, and a Permissions-Policy that turns off geolocation, mic, camera, and payment outright.
  • A server-side order endpoint. Orders no longer depend on the browser surviving the round trip — a Pages Function at /api/order takes the submission, so the order is recorded server-side and the Meta Conversions API event fires from the server with properly hashed customer data.
  • Assets I control. The bundle-pack art went from 10.6MB to 0.34MB across 12 files — a 97% cut on the heaviest images in the line, impossible while a hosted builder owned what got served.
  • Deploys in seconds. wrangler pages deploy against a git repo, instead of repasting HTML into an editor and re-uploading to Pancake. That difference is why the polish phase kept moving.
  • A codebase agents can work in. Plain HTML, CSS, and JS in version control reads cleanly to an AI coding agent. A page builder's proprietary editor does not. Every improvement since the migration has been faster for exactly this reason.

The order-ops pipeline. This is the part that lives outside the page itself:

  • Order modal → Facebook Messenger. Modal submit deep-links the customer to the Shinjiru Facebook page with their selected bundle pre-stamped in the conversation context.
  • Botcake confirms the order. The Messenger bot collects any missing detail, confirms the bundle and total, and triggers the order-receipt email.
  • Gmail → Google Apps Script → Google Sheets. An Apps Script polls Gmail for new order receipts, parses them, and appends each order as a row in the canonical orders Sheet. The Sheet is the single source of truth.
  • Pancake POS pulls from the same Sheet for fulfillment tracking — packing slips, courier handoff, status updates.
  • Meta Pixel fires the conversion event on order-CTA submit so paid ads can be optimized against actual orders, not just landing-page clicks.

The five funnels with their color territories, each on its own subdomain — click any to open the live page in a new tab:

Gut In Shape — gut health capsule, navy treatmentOpen live
Cravelle — cravings oil, cream treatmentOpen live
Lunea — sleep oil, lilac treatmentOpen live
Calmara — stress oil, deep-purple treatmentOpen live
Red Lava — carbo-block slimming juice, molten-red treatmentOpen live

Timeline

The engagement compressed into roughly three weeks of focused build work after the initial assets and details landed.

  • April 25 — kickoff meeting. Brand alignment, scope confirmation, asset audit. No build work yet.
  • April 29 — build start. Clean-v1 scaffold goes up. First product page wired end-to-end.
  • May 9 — clean-v2. Founder section, Pexels hotlinked imagery, copy locked, first cross-product visual audit.
  • May 12 — clean-v3. Vertical video rows, sound-aware testimonial autoplay, local background asset migration off Pexels for production.
  • May — polish pass. Fluid type scale, urgency block clickable, hero mobile cap, ingredient card compaction, "in real life" section heading.
  • June–August — the Cloudflare rebuild. Each product converted to a self-contained site in its own repo, assets bundled and compressed, security headers and the server-side order endpoint added, and every funnel moved onto its own subdomain.
  • August — Red Lava launches. The first product built standalone from day one: no page builder, straight onto redlava.shinjiruwellness.ph with the hardened build and server-side attribution already in place.

Iteration discipline: every global edit rebuilds all previews together. A change that looks right in Gut In Shape gets verified in Cravelle, Lunea, Calmara, and Red Lava before it lands.

Outcome

Five funnels live, each on its own subdomain: calmara, cravelle, gut-in-shape, lunea, and redlava at shinjiruwellness.ph. Order flow routes through Facebook Messenger via Botcake, orders post to a server-side endpoint and auto-populate the canonical Google Sheet via Apps Script, Pancake POS pulls fulfillment data from the same Sheet, and conversions report to Meta from both the browser and the server.

The clean-v3 globals architecture cut per-page payload roughly 60% versus the inline-everything approach the build started from; the Cloudflare rebuild then took the bundle-pack art down another 97%, from 10.6MB to 0.34MB. Each product carries its own 30-day bonus pack — diet, sleep, or stress management — wired into the page's value stack so the perceived offer is consistent across the line.

The shape of the win is the part worth keeping: the same funnel that a hosted builder shipped fast, rebuilt as files I own, got faster, safer, easier to integrate with the POS and messaging stack the operator already runs, and quick enough to deploy that improving it stopped being a chore. Red Lava is the proof — a brand-new SKU launched straight onto the hardened build with nothing to migrate.

What I'd repeat

Three patterns carried this engagement.

Globals-first architecture. Once WebCake exposed the four injection slots, every shared concern — typography, color territories, animations, modals, countdowns, attribution — moved into a single place. Per-page HTML became thin per-product content wrapped in a data-product attribute that drives theming from global CSS. The system can't fork because there's nothing to fork — one shared source of truth, five data-attribute variants.

Route the conversation, don't recreate it. Instead of building a custom checkout inside the landing page, the order CTA routes the customer into Facebook Messenger where Botcake handles confirmation conversationally. That's the channel PH buyers already trust. The landing page's job is to convert the click — Messenger's job is to convert the conversation. Apps Script glues the two together by pulling Botcake's order receipts out of Gmail into the operator's Google Sheet, and Pancake POS reads from there. The whole pipeline is composed of tools the operator already pays for; nothing custom is hosted, nothing custom needs to be maintained.

Ship on the fast thing, then move when it starts costing you. WebCake was the right call at kickoff — it got the line live in weeks without a build pipeline to stand up first. It was also the right call to leave once the constraint flipped from "how fast can this launch" to "how fast, how safe, and how deeply integrated can this get." Migrating a working funnel is a real risk, so it ran additively: build the standalone version alongside the live one, verify it, move the traffic, retire the old page. No downtime, no rewrite-from-scratch, and no loyalty to the platform that got it started.

Need a similar engagement?

Book a call →