"Now's the time": we took Shopify up on the UCP challenge

Harley Finkelstein, Shopify's President, posted this:

Last month, we opened Shopify Catalog to all developers. And soon, they'll be able to earn commission on sales their shopping experiences drive. Build it and earn from it. Devs, if you're not building with UCP yet, now's the time.

Consider this our reply. We built the thing.

It is called  Frunk & Trunk , an accessory index for electric vehicles. You pick your Tesla or Rivian, then browse or search and compare the same gear across shops before you buy. It scratches an itch I have as a Tesla owner (EV accessories show up in a dozen stores under a dozen names at a dozen prices), but the honest reason it exists is the one in Harley's post: the Universal Commerce Protocol and Shopify Catalog are open to every developer now, and the best way to understand new commerce infrastructure is to ship something real on it.

Here is what we took away, written for the people who will actually appreciate it.

Build it: what UCP changes

Traditionally, if you wanted to surface products from many merchants, you scraped, you integrated one store at a time, or you wrangled feeds. UCP flips that. You register an agent profile in the Developer Dashboard, call the public catalog MCP endpoint, and get back live, structured listings from across the network. No approval queue, no per-merchant integration.

For a builder, that is a genuinely different mental model. Frunk & Trunk holds no inventory, syncs no feeds, and stores no product data. It is a thin, fast discovery surface sitting on top of live catalog queries. The entire vertical (which vehicles, which accessory categories, which queries) lives in one config file, and the catalog does the heavy lifting.

A few specifics that will save you time if you head down this path:

• Live means live, and it is a rule, not a preference.  We fetch per request and cache nothing, with  Cache-Control: no-store  everywhere. Prices are correct at the moment of page load, which is exactly what you want when you are a comparison surface rather than the merchant of record.
• Model your identifiers carefully.  The catalog does multi-seller clustering, and a product identifier and a variant identifier are not interchangeable. A product-level lookup can return a different default seller than the specific offer a search card showed. We anchor cards to the variant that owns the offer so price, store, and checkout stay consistent, and keep canonical and "similar" links at the product level. Get this wrong and your prices quietly disagree with themselves.
• "Similar" is a ranking signal, not an equality claim.  The EV accessory market is full of white-label duplicates, so cross-shop comparison is the entire value. But similar listings are not the same SKU, and we never merge them as if they were. Honest comparison depends on respecting that line.
• Schema yourself as what you are.  We emit JSON-LD Product schema, deliberately not merchant-listing schema, because we are a discovery and comparison site, not the seller. No shipping badges, no return policies, no invented ratings.

Earn from it: on your own terms today, natively soon

The second half of Harley's post is about earning, and this is where a project like ours gets interesting. Frunk & Trunk already monetizes through transparent affiliate links, disclosed plainly at the point of the link and on a dedicated  disclosure page . We are a comparison tool, not a store, so there are no fake reviews or shipping badges anywhere on it.

The commission layer Shopify is rolling out points at exactly this: shopping experiences that earn from the sales they drive, built into the protocol instead of bolted on network by network. If you are already thinking about how a discovery surface pays for itself, UCP is lining up to make that a first-class part of the stack.

The bar: ADA, AEO, and performance, with no trade-offs

The API was the reason to start. The discipline was the point. We set three standards up front and refused to negotiate them down, because a build that ships fast but fails on accessibility or discoverability is only half done.

ADA / accessibility.  WCAG 2.2 AA throughout, as a starting constraint rather than a final pass. Native HTML controls, one clear heading per page, visible keyboard focus, live-region announcements, automated contrast checks before anything ships, and a published  accessibility statement . Most visitors never notice any of it, which is the goal.

AEO (answer engine optimization).  Product discovery is shifting from search boxes to AI assistants, and those assistants mostly do not execute JavaScript. So every core page is server-rendered with live catalog data, marked up with Product JSON-LD, and backed by a clean sitemap and an  llms.txt . If your catalog content only appears after a client script runs, an answer engine never sees your products. Server-render the commerce data. In a world of agentic commerce, being machine-readable is not a nice-to-have.

Performance.  All of that usually comes with a tax, and here it did not. The site is framework-free, has no client-side rendering to wait on, ships minified assets, and runs on Vercel's edge. We just ran Lighthouse and scored  100 across all four categories: Performance, Accessibility, Best Practices, and SEO.  Live, uncached catalog data and a perfect performance score in the same build was the exact thing we were curious whether we could pull off. We could.

So, now's the time

Frunk & Trunk is a passion project, not a revenue play. But it is a proof, in public, that UCP is ready for real, polished builds, and that "new API," "fully accessible," "AI-readable," and "genuinely fast" are not competing goals. Built carefully, on this catalog, they are the same goal.

Harley said now's the time. He is right. If you are exploring UCP too, we would love to compare notes. And if you just want to see the result:  frunkandtrunk.com .