Problem

I was testing external vendors for a virtual try-on system. The results weren't good enough: products didn't look real, and the user's uploaded photo wasn't reprocessed—the garment was simply pasted on top. And the bill? The AI model, plus the vendor's margin on every single run. Same stack, inflated price.

Solution

I started thinking a virtual try-on app isn't that complicated to build. It comes down to the AI model, the prompt, how product photos are presented, and how fast you can generate. So I built a POC and tested several models—generic ones and others specialized for virtual try-on. I iterated on the prompt until the user's photo and the product were accurate, end to end.

I landed at 6–8 seconds per generation, with products rendered convincingly. Then I built the embeddable script so brands can drop it on their site—and DRIPT was born. No reseller in the middle: you pay only the model's inference cost, at provider rates—not list price plus platform fees. The carousel shows some of the first results.

If there's one lever that makes the difference between a decent output and a great one, it's always the prompt you send to the AI. Everything else matters—but that part is non-negotiable.

Outcome

A virtual try-on you integrate with a script import—realistic output, no pasted-on garments. In practice, roughly one-fourth of what we were quoted by external vendors, because the economics are transparent: model cost only, no markup layer. Fast enough for product pages, with quality driven by model choice and prompt engineering. Better try-on, better unit economics.

Problem

SFCC's native approach to delivering content differentiated by language and country relies on the integrated localization system, which requires uploading an HTML content asset and then duplicating it for each language-country combination to manage. This process is time-consuming, error-prone, and creates maintenance overhead when updates are needed across multiple markets.

Solution

I created a single reactive template that adapts to both language and country. I worked with the core development team to add data-lang, data-country, and data-currency attributes to the HTML tag. This enables a single HTML file with JavaScript that dynamically manages language and content based on the current country and language context. Simple, right?

Outcome

What previously took an hour just to upload a single content asset now takes 2 minutes. The centralized template approach eliminates duplication, reduces maintenance complexity, and ensures consistency across all markets. Updates propagate instantly across all language-country combinations without manual intervention.

Problem

A/B tests that require heavy transformations and loading new images—such as changing images in Product Listing Pages (PLP) or homepage—often cause flickering when modifications are injected directly via ABTasty. This flickering occurs because ABTasty's JavaScript executes after the page starts loading, creating a visible delay where users see the original content before the test variant is applied. For complex experiments that would typically require server-side A/B testing, this client-side approach creates a poor user experience.

Solution

I developed a cookie-based workaround that eliminates flickering completely. Instead of injecting modifications directly through ABTasty, I use ABTasty to inject a cookie with the test name. On the site side, I listen for ABTasty's tag, and if the session has an active experiment, I read the cookies and inject the modifications directly from the frontend before the page renders. This approach ensures that changes are applied synchronously during page load, eliminating any visible flickering or content shift.

Outcome

This workaround completely eliminated flickering, even for the most complex A/B tests that would have normally required server-side implementation. The solution enables complex experiments—including image replacements, layout changes, and heavy DOM transformations—to run smoothly without any visual artifacts. This approach provides the benefits of server-side A/B testing (no flickering, seamless experience) while maintaining the flexibility and ease of client-side testing tools.

Problem

This is the project I'm most proud of at GUESS, simply because it was the first one—first love never forgotten. Everything started from here. When I was hired, I was a Web Operations Specialist. Although I had a background in design and development, I had accepted a different position to move from Puglia to Northern Italy and have the opportunity to work with dignity. I found myself in a large, beautiful, exciting company, but what I had to do was boring. I would have had to spend entire days scheduling content.

The old GUESS website management system was a proprietary, slow, and cumbersome system: to upload a banner, even if the HTML was the same, you had to repeat the procedure once for each language and brand (10 languages and 3 brands at that time) and once for each page. The first week I spent 10 hours a day scheduling content. The second week I wanted to quit! I felt I had made a mistake accepting the position and that I couldn't do "manual" and repetitive work.

Solution

Then came the idea. In the second week, I thought: wait, I can automate this. In 2016, there weren't many automation tools available, so I created a simple but effective JavaScript system. A script injected via a Chrome extension that added a console where I could upload HTML files, set start and end dates, specify the URL, and click a fantastic "RUN" button that simulated exactly what I would have had to do manually (today you could do this with Selenium or other automation tools). When I ran the script for the first time and saw the screen moving on its own, I was moved XD.

The second optimization I made in the third week was switching to API calls to automate operations. I couldn't believe it—programming everything took one hour instead of 10. From here began my entire professional journey.

Outcome

Codie Automator transformed a 10-hour daily manual task into a 1-hour automated process, representing a 90% time reduction. More importantly, it freed me to focus on higher-value work, leading to the development of all subsequent automation and optimization projects. This was the foundation that enabled my growth from a Web Operations Specialist to a Senior Frontend Developer, proving that automation and innovation can transform not just workflows, but entire careers.

Problem

Size charts in SFCC were managed at GUESS using content assets. There were at least 100 different assets, each containing a size table to be referenced for a specific product. When I was first asked to modify the UI of the size charts, I realized the system was fundamentally flawed—maintaining and updating 100+ separate assets was unsustainable.

Solution

I rebuilt the entire system by separating data from the frontend. Content assets were reduced from 100 to 1 single asset. This unified file calls the correct configuration from a JavaScript file containing all size chart data. The system exports only the specific values needed by the frontend, keeping it lightweight and performant without unnecessary data overhead.

Outcome

The architecture transformation eliminated 99% of content asset duplication. Updates to size chart data or UI now happen in a single location, with changes propagating automatically across all products. The system is maintainable, scalable, and significantly reduces the risk of inconsistencies across the product catalog.