One Engine, Two Storefronts

Most software teams solve "we need this feature on a second product" by copying the code, renaming a few things, and quietly accepting that the two copies will drift apart within a year. It's the path of least resistance, and it's also how most companies end up with three slightly different versions of the same idea, each with its own bugs, each fixed separately, forever.

Creytix's operating rule is the opposite of that path: a capability usable by two or more products isn't forked — it's built once, owned centrally, and issued to each product as a service. The product gets to configure how it looks and where it sits in the page. It doesn't get its own copy of the logic.

The clearest live example of that rule paying off is a price-compare engine.

The problem it solves

If you're shopping for an auto part, "cheapest listed price" and "what this actually costs you" are two different numbers, and the gap between them is where a lot of bad purchase decisions live. Shipping, warranty terms, seller reliability, and total landed cost all matter — and most storefronts either ignore that complexity (show the sticker price and move on) or bury it in a spec sheet nobody reads before checkout.

Expedia Parts needed a way to show shoppers a real side-by-side: not just "this one's $4 cheaper" but "here's the total cost, and here's what's different about the deal." That became Compare & Earn — the comparison and reward experience live today inside the Expedia Parts storefront.

Separately, on the AlignAlgo side of the portfolio, Align Shop exists to answer a related but broader question: not "which auto part is cheapest," but "which option, across retailers, actually fits you — total cost, shipping, warranty, confidence — not just the lowest number on the label." Same underlying job: rank options by what actually matters, not by sticker price alone.

Two different products. Two different audiences. The same underlying problem, structurally.

The build-once decision

The obvious approach would have been two engines: one tuned for Expedia Parts' catalog and comparison logic, one built fresh for Align Shop's broader "best fit for you" framing. That's the fork-and-drift path — and it's the one Creytix's tool-homing rule explicitly rules out. The rule reads, in practice: if a capability is useful to two or more apps, it becomes one Creytix tool, owned centrally, consumed by both. The per-app differences live in configuration and data, not in a second copy of the engine.

So the comparison and ranking engine got built once, as a Creytix-owned capability, with the specifics of "how EP's catalog maps into it" and "how Align Shop's retailer data maps into it" treated as per-app configuration on top of a shared core — not as two different codebases solving the same problem twice.

What shipped first, and is live today, is the Expedia Parts side: Compare & Earn, running in production inside expedia-parts-front, using that shared engine. It's the same engine designed, from day one, to power Align Shop's comparison experience when that product is ready to launch — built once, intended to run everywhere it's needed, not duplicated per brand.

What this looks like from the inside

The practical UX and velocity difference shows up in a few concrete ways:

A bug fixed once is fixed everywhere it's deployed. If the comparison logic mis-ranks something — say, undercounting shipping cost in a total — there's exactly one place to fix it. Every product consuming the engine inherits the fix on its next deploy. There's no second copy quietly still carrying the same bug six months later because nobody remembered it existed in two places.

A UX improvement compounds instead of resetting. When the comparison interaction gets sharper — clearer total-cost breakdowns, better confidence signals, faster load — that improvement is a change to the shared engine's contract, not a one-off patch to one storefront's page. The next product that plugs into the engine starts from the improved baseline, not from scratch.

The second integration is dramatically cheaper than the first. The expensive part of building a comparison engine — the ranking logic, the total-cost math, the confidence scoring — gets paid for once. Standing up the second storefront's version of it becomes a configuration and data-mapping exercise, not a rebuild. That's the entire economic case for "build once, run everywhere," made concrete instead of aspirational.

The brand still looks and feels native. None of this means Align Shop will look like a reskinned Expedia Parts page. The engine handles ranking and comparison logic; each product's own front end decides how that logic gets presented — copy, layout, visual language all stay per-brand. What's shared is the machinery underneath, not the storefront.

Why this matters beyond one feature

This one engine is a small, concrete instance of a much larger operating principle behind Creytix: capabilities live in the platform, and products consume them, instead of every product accumulating its own private, slowly diverging version of everything it needs. Multiply "one engine, two storefronts" across image pipelines, review-and-approval flows, deploy governance, and content generation, and the pattern is the same everywhere — the machine gets smarter once, and every brand running on it gets smarter with it.

That's also the honest way to read "one engine, two storefronts" as proof, rather than as marketing shorthand: it's not a claim that Align Shop is live today — it isn't, it's still in build — it's a claim about what happens when the engine that will eventually power it is already proven, in production, carrying real comparisons for real shoppers on a different brand. The second storefront isn't a bet on unproven logic. It's a configuration exercise on top of logic that already works.

Build once. Prove it in production on one brand. Reuse it, don't rebuild it, on the next. That's the entire idea, and the reason it's worth writing about isn't that it's a clever trick — it's that most software organizations know this is the right answer and still don't do it, because the org chart or the codebase or the incentive structure makes forking easier than sharing. Creytix's tool-homing rule exists specifically to make sharing the easier path, not just the theoretically correct one.