Real, live, first-party proof

The situation

Expedia Parts, Expedia Engines, and Expedia Transmissions are three separate, live storefronts serving overlapping but distinct auto-parts markets. Running three brands as three completely separate engineering efforts is the default failure mode for multi-brand operators — triple the maintenance, triple the drift, triple the places a bug can hide.

What Creytix does here

All three storefronts run on the Creytix stack — the same governed deploy pipeline, the same image and content pipeline, the same brain governance layer deciding what an AI agent can do autonomously versus what needs a human sign-off. They're differentiated by brand, catalog, and customer experience — not by three different underlying engineering approaches.

What's actually live

Real transactions, running today, on all three storefronts, on the Creytix stack. This isn't a staging environment or a demo catalog — it's the production system a real business depends on daily.

Why it matters as proof

This is the load-bearing case for "Creytix ships and runs the client," made concrete. It's not a claim about what the platform could do for an outside customer — it's a description of what it's already doing, every day, for a real, multi-brand, transacting business.

The situation

AlignHeart is a relationship-coaching platform — a genuinely different product category from an auto-parts storefront, built by a different team persona, serving a different customer, with a completely different UX and compliance surface (coaching disclaimers, crisis-resource routing, a named-coach model instead of a swipe-and-match model).

What Creytix does here

The full pipeline — assessment intake, compatibility scoring across named dimensions, and coach-path routing — is built and operated on the same Creytix platform used for the auto-parts storefronts. Different product, different brand voice, different user journey entirely — same underlying operating machine.

What's actually live

AlignHeart is live at alignheart.com, with the assessment → compatibility → coach-path routing flow working end to end, today, for real visitors.

Why it matters as proof

It demonstrates the platform isn't a one-trick engine tuned to e-commerce. A coaching product with an entirely different shape of user journey runs on the exact same governance, deploy, and content machinery as a parts storefront — which is the actual test of "operating platform" versus "e-commerce template."

The situation

Two different brands under the portfolio both needed a "which option actually serves this shopper" comparison capability — Expedia Parts for auto parts total-cost comparison, and Align Shop (the shopping product under the AlignAlgo umbrella) for a broader personal-fit ranking across retailers. The default approach — build it twice, once per brand — guarantees drift: two comparison engines, two sets of bugs, two places to improve the ranking logic separately.

What Creytix does here

Per the platform's tool-homing rule (a capability usable by two or more products becomes one Creytix-owned tool, not a fork per brand), the comparison and ranking engine was built once, as a shared Creytix capability. Each brand configures how it's presented and what data feeds it; neither brand carries a private copy of the underlying logic.

What's actually live

The engine is deployed and live today inside Expedia Parts' storefront as Compare & Earn — real comparison logic, running in production, for real shoppers. It is the same engine designed to power Align Shop's comparison experience when that product launches; Align Shop itself is still in build, not yet publicly live — the honest framing here is "one proven engine, one live consumer today, one more storefront designed to run on it next," not "two live storefronts."

Why it matters as proof

It's the clearest concrete instance of "build once, run everywhere" as a real engineering decision, not a slogan — a bug fix or a UX improvement to the shared engine benefits every brand that consumes it, and the second brand's integration cost is a fraction of the first because the hard logic is already proven.

The situation

Remanufactured engines and remanufactured transmissions are related but distinct auto-parts categories — different catalogs, different fitment logic, different buying intent — and a shopper looking for one is rarely looking for the other. Splitting them into two focused storefronts, rather than one undifferentiated catalog, is the right call for the customer. It's also, by default, twice the engineering surface to maintain.

What Creytix does here

Both storefronts run on the same stack as the Expedia Parts flagship — same governed deploy pipeline, same content and image pipeline — configured per-brand rather than forked per-brand. Each has its own live domain and its own defensive redirect: www.expediaremanengines.com 301s to the canonical epengines.com, and www.eptransmissions.com 301s to epttransmissions.com — both patterns verified live and resolving to real, brand-specific storefronts, not placeholder pages.

What's actually live

epengines.com serves "Expedia Reman Engines | Premium Remanufactured Engines"; epttransmissions.com serves "Expedia Transmissions | Remanufactured Transmissions" — both verified 200, both real catalog content, both distinct from the flagship Expedia Parts storefront in positioning and inventory.

Why it matters as proof

This is the same "build once, brand many" claim as the flagship three-storefront story, verified again independently at the DNS and content level — two more live storefronts, two more domains, zero forked engineering.

The situation

The first version of a verified-review product is almost always built to solve its founder's own immediate problem — in this case, trustworthy reviews for auto-parts fitment. The trap is stopping there: a product that only makes sense for the vertical it was born in isn't a platform, it's a feature with one customer.

What Creytix does here

EarnedStar deliberately generalized past its starting point — reviews tied to a confirmed purchase, screened before publish, with vertical-specific configuration (like fitment attributes) treated as optional merchant config rather than a hardcoded assumption. The brand identity itself reflects the shift: no auto-parts-only positioning in customer-facing copy, a name and tagline ("Only verified buyers earn your stars") built to mean the same thing for any merchant as it does for an auto-parts storefront.

What's actually live

earnedstar.com is live and verified (title: "EarnedStar — Only verified buyers earn your stars"), with a separate iOS build in progress and a shared backend serving the review and fraud-screening pipeline.

Why it matters as proof

It's evidence the platform doesn't just replicate one business twice — it builds genuinely reusable products, with the automotive use case as one tenant among the ones it's designed to support, not the ceiling of what the product can be.

The situation

The tempting version of a new marketplace idea is to build the whole thing — catalog, cart, checkout, vendor onboarding, payments, logistics — and hope demand shows up after. That's also the most expensive way to find out an assumption was wrong. GoTianguis's honest history is a case study in resisting that temptation mid-build.

What Creytix does here

A full owned-stack Next.js storefront — catalog, cart, checkout flow, customer accounts, order history, SEO — was built as the marketplace's foundation. Partway through, the most recent, most authoritative product decision narrowed scope on purpose: rather than push forward on the full marketplace, the near-term plan is a deliberately small 90-day pilot — claimable vendor pages via WhatsApp onboarding, no payments, no checkout, no logistics — built to answer one question (will real tianguis vendors actually claim and share a free page) before any further marketplace investment.

What's actually live

gotianguis.com resolves and serves the real storefront app today, with payments explicitly gated off behind a feature flag — the UI reads "Enrollment / checkout coming soon," and the order API only accepts pending-payment requests, not completed transactions. This is a real, running application with monetization intentionally not yet switched on, not a placeholder.

Why it matters as proof

It shows the platform's discipline extends to product strategy, not just engineering — the willingness to pause a mostly-built feature set and test a smaller, cheaper hypothesis first is exactly the kind of honest self-correction the rest of this launch pack tries to model.