RΞCIPΞ Move case: from generator architecture to e-commerce catalog
RΞCIPΞ Move is an own product of the ecosystem that shows the ENEY approach works for more than a quick business-card website. The same logic — data → generator → pages → schema → sitemap → QA — scales to a more complex catalog with products, pricing, collections, multiple languages, a blog and e-commerce rules.
This is an own product of the ecosystem, not an external client case. That's exactly why it can be shown in more depth: how the structure is built, how the generator works, what QA checks, and how the site is prepared for Google.
What this project is
RΞCIPΞ Move is a car-fragrance catalog with product pages, collections, informational pages, a blog and an English version. Unlike ENEY, which sells services, Move works with real products, so it uses Product / Offer schema, prices, availability, a return policy and e-commerce logic.
Why this case matters for ENEY
ENEY isn't just showing that it can build a good-looking page. RΞCIPΞ Move proves that the generator architecture and QA discipline can hold a bigger system: many products, collections, a blog, multiple languages, a sitemap, schema, checks.
The same model that lets you launch a website quickly can scale to a catalog without rewriting everything from scratch.
Verified numbers
Architecture
Instead of copying pages by hand, the site is generated from data: data/scents.json, data/sets.json and data/blog.json pass through generate.js and become HTML pages, schema markup, a sitemap and a QA report. This keeps structure, prices, availability statuses, SEO metadata, schema and the sitemap controlled from one source.
- data/scents.json, data/sets.json, data/blog.json
- generate.js
- HTML pages
- schema (Product/Offer, BreadcrumbList)
- sitemap.xml
- QA script
How Move is more complex than ENEY MVP
ENEY MVP
- service pages
- Service + Offer
- a case study
- Launch Base
- a request form
RΞCIPΞ Move
- product pages
- prices and SKUs
- availability
- collections
- a blog
- an English version with hreflang
- Product / Offer schema
- MerchantReturnPolicy
- more URLs in the sitemap
- more QA risk
It's a different class of task. If ENEY MVP proves launch speed, Move proves that the approach scales.
Correct schema logic
Move uses Product / Offer schema because it has physical products. ENEY uses Service + Offer because ENEY sells services. That's not a coincidence — it's a principle: schema should match the real nature of the page.
Product schema from Move is not carried over into ENEY's services.
Reviews and ratings, without fakes
Move has a useful pattern: aggregateRating and reviews only appear in schema when the data has real rating and reviews fields. If there's no real data, the markup isn't generated. ENEY has the same logic prepared for future real reviews, but nothing is shown yet, because there's no real data.
QA discipline
Move has a stronger QA script: it checks not just syntax but quiet generation errors — broken links, broken images, incorrect statuses, artifacts like undefined, NaN, [object Object], empty values. This matters because a static generator can create many pages fast. But without QA, it can multiply one mistake across dozens of URLs just as fast.
What we're carrying over from Move into ENEY
- checks for quiet generation artifacts (
undefined,NaN,[object Object]) - conditional reviews/ratings for real data only, no fakes
- wider BreadcrumbList logic across internal pages
- per-page OG images for cases and services
- a plan for splitting the generator into modules in the future
- case metrics as proof of system complexity
What this case proves
RΞCIPΞ Move shows that ENEY isn't just about “building a page fast”. It's an approach to launching a digital system: structure, data, design, schema, sitemap, QA, and the ability to scale.
Related services
Catalog MVP
A catalog of products or services that can already take requests.
Launch Pack
A website, structure, copy, design and launch in one process.
Business Site
A company website without months of waiting.
