TL;DR
Moby builds a complete, conversion-focused landing page from a single chat request, for any product, offer, or campaign goal. It draws on the brand's style, ad performance data, and real product data, then publishes the page through Shopify's app proxy so it is part of the live site,. An existing page can also be duplicated and adapted, or set to change its content by UTM parameter.
Overview
Most page builders start from a blank template. Moby starts from research, studying what actually sells the product before writing any content, so the page is informed rather than generic.
A page can start three ways: a new page from a written prompt, a saved landing-page template, or a duplicate of an existing page adapted around a different offer, audience, or ad angle.
Key terms
Term | Definition |
App proxy | The Shopify mechanism that serves Moby's page under the brand's own domain, inheriting the live theme's header and footer. |
Brand Vault | The brand's stored style guide (colors, typography, voice) that Moby pulls from automatically. |
Blueprint | The section-by-section layout spec Moby produces before writing any page content. |
QA checklist | The pass/fail accessibility, responsiveness, and functional checks Moby runs before handoff. |
UTM parameter | A tag added to a URL that identifies the traffic source, used here to control which content version a visitor sees. |
Dynamic content | Page content, such as product details or imagery, that changes automatically based on a UTM parameter. |
How it works
What it analyzes
Before writing anything, Moby pulls from three sources: the brand's style guide (Brand Vault), the last 90 days of Meta and TikTok ad performance (ROAS, CPA, CTR, conversions, to surface the winning hook and audience), and the product's real images, reviews, and policies from Shopify. These insights are saved in the shop's memory and reused on future pages.
How a page is built and checked
Moby works in two phases. In research, it produces a layout blueprint covering mobile, desktop, and large screens, with verified color-contrast values and a pass/fail hero checklist: one headline tied to the winning ad hook, one price, one CTA, verified review proof. No claim, rating, or price is added unless it traces to a verified source; an empty slot is preferred over a fabricated one. In build and QA, Moby turns the blueprint into a page and checks responsiveness, WCAG contrast minimums (4.5:1 normal text, 3:1 large text), and functional behavior, such as sold-out variants never being selectable. A pass/fail checklist is printed in chat before handoff.
How it's served
The page is delivered through Shopify's app proxy, at a URL such as https://yourstore.com/apps/load/<page-slug>. This makes it part of the live site: same domain, same header, footer, navigation, cart, and native scripts (cookie consent, tracking pixels) as the rest of the store. No theme file is edited and no new page appears in the theme's page list, so pages can be created and removed with no risk to the live theme.
Image generation
By default, Moby generates the hero image by compositing the real product into a scene. The product's silhouette, finish, logo, and proportions are never redrawn or altered; an existing photo is used only if it already fits the hero's composition requirements. The same rule applies to every generated image on the page.
Duplicating and adapting existing pages using Moby
An existing live or draft page can be duplicated and adjusted around a different pain point, offer, or ad angle, for example, a version of the main product page built around a specific Meta ad's objection, instead of building a new page from zero.
Dynamic content by UTM parameter
Moby can write a script that changes a page's product details or imagery based on a UTM value in the URL, so one published page can serve several ad angles or audiences without a separate build for each.
For an exact prompting guide from original idea to published landing page read "How to create landing pages with Moby"