OOTOPIA

• 

  landingpage

Inspiration

Beauty tutorials are inspiring, but they usually stop at inspiration. A creator’s look is presented as a fixed list of products, even though every user has different visible skin context and may already own products that can recreate most of the result. We built Ootopia to close that gap. Instead of asking people to copy a look blindly or buy an entire new routine, Ootopia turns a creator look into a personal, explainable makeup recipe.

What it does

Ootopia is a mobile-first beauty PWA for remixing creator makeup looks. A user can browse a creator look, start a private remix, give explicit consent, capture an image, and run YouCam Skin Analysis to obtain cosmetic context such as tone, texture, oiliness, redness, and pores. The user then chooses a cosmetic goal, such as reducing shine or keeping glow. Ootopia matches the creator’s look against products in the user’s own makeup kit and explains what is:

• already owned;
• substituted with a close product;
• genuinely missing. The adapted recipe can then be rendered with YouCam Makeup VTO as a private preview. If the user chooses to share it, Ootopia publishes an attributed derivative without publishing the original facial image.The user can delete their facial data at any time. The deletion flow removes the stored facial resource and creates a deletion receipt. Ootopia does not provide medical diagnosis, attractiveness scores, guaranteed cosmetic results, or exact product-equivalence claims. ## How we built it The frontend is a React 19 progressive web app built with Vite, Tailwind CSS, HeroUI v3, and a mobile-first responsive design system. The backend uses Cloudflare Workers, D1, R2, and Queues:
• Workers handle static PWA delivery, API routes, authentication, and policy enforcement.
• D1 stores users, creator looks, remix plans, kit items, AI jobs, and deletion receipts.
• R2 stores private facial media, private try-on results, and approved public derivatives.
• Queues run asynchronous Skin Analysis, VTO, and lifecycle jobs.
• Scheduled recovery handles due jobs and retention cleanup. YouCam Skin Analysis and Makeup VTO are integrated through server-side adapters. The browser never calls YouCam directly. The browser polls Ootopia’s job state while the Jobs Worker submits and polls provider tasks. The recipe adaptation engine combines the creator’s structured look, the selected cosmetic goal, normalized skin context, and the user’s owned products. It produces explainable owned, substituted, and missing decisions instead of an opaque score. The demo uses an authorized synthetic facial fixture for the live scan flow. Original facial media remains private and can be deleted explicitly. ## Challenges we ran into The main challenge was making asynchronous provider tasks feel like one reliable user journey. YouCam uses separate file-upload, submission, and polling contracts. During integration, we corrected the file-ticket payload shape, normalized the Skin Analysis response, excluded auxiliary provider outputs, and mapped the Makeup VTO response to the correct result URL. VTO rendering can take longer than a short request timeout. We changed slow provider polling from a terminal failure into a retryable state with bounded backoff. The UI flow also exposed a data-model issue: a remix plan could be created before the skin scan existed. We fixed the flow so the plan binds to the user-owned scan during goal selection. Privacy was treated as a product requirement. Private R2 objects are never exposed directly, publishing creates an explicit derivative, and facial-data deletion removes the stored resource and records an auditable receipt. and the tight deadline time as well is the main challenges am faced. ## Accomplishments that we're proud of We completed and verified the full journey:

creator look → consent → capture → live YouCam Skin Analysis → cosmetic goals → recipe adaptation → live YouCam Makeup VTO → publish with attribution → facial-data deletion

We are proud that the workflow explains the result through owned, substituted, and missing products instead of forcing a generic recommendation.

We also built Ootopia as a mobile-first PWA. It works in a browser without requiring an app-store installation. but yet this app needs more polished.

What we learned

We learned that provider integration is more than sending one API request. It requires durable job state, retries, idempotency, response normalization, quota protection, and honest evidence about which parts actually executed.

We also learned that privacy must be visible in the product flow. Consent, private storage, retention, deletion, and attribution should be understandable to users instead of hidden in technical documentation.

Finally, explainability creates more trust than a single opaque score. Showing why a product was kept, substituted, or marked missing makes personalization easier to understand.

What's next for OOTOPIA

Next, we want to improve creator-source importing across supported public platforms, expand the structured look catalog, and make kit onboarding faster without sacrificing explanation or privacy.

We also want to use judge and user feedback to refine the mobile journey, improve accessibility, and expand recipe adaptation across more cosmetic goals and product categories.

Built With

• cloudflare
• css
• d1
• javascript
• typescript