Do you build stores from scratch, or only work on existing ones?

Both. Some clients come to us without an ecommerce operation at all and we build it; more often the system already exists and the work is migrating it, stabilising it, or keeping it fast as it grows. The published cases here are all of the second kind, which says more about which projects became case studies than about what the team does.

Which platforms do you actually work on?

Adobe Commerce, VTEX and Shopify, the three the team holds certifications on. Naming a longer list would mean naming platforms we have never had to fix at three in the morning. On the storefront and the app side the work is React and React Native.

Can you migrate a store without taking it down?

Yes, and Lentesplus is the published example: a high-traffic store selling across four countries moved from Magento Open Source 1.9 to Adobe Commerce Cloud while it stayed in active use, with new requirements arriving throughout. What that costs is planning rather than downtime: there is no frozen version to work from, so the sequence has to absorb a moving baseline.

What does ongoing work look like?

Weekly releases and daily fixes, with priorities set against revenue rather than against a backlog order. On KURU that meant certified developers working part-time and shipping every week rather than a large team shipping every quarter, starting with the checkout errors that were costing sales every day.

Do you handle accessibility?

Yes, and on TGI Fridays it was audited rather than assumed: automated tooling plus manual testing of how people actually moved through the menu and the checkout, with semantic HTML and keyboard navigation built into the design system so later brands stayed accessible by default.

Retail & Ecommerce

What we’ve done under real traffic

Four projects on systems that could not be taken offline while the work was happening.

A live migration off Magento 1.9, across four markets
Lentesplus sells vision care in Colombia, Argentina, Chile and Mexico on a high-traffic store that could not stop selling. We moved it from Magento Open Source 1.9 to Adobe Commerce Cloud while new requirements kept arriving and the site stayed in active use, which is why there was never a stable version to migrate from. The engagement then became a multi-year team embedded in theirs.
Lentesplus. Migration, then continuous platform development. Adobe Commerce Cloud and React.
Two years of a broken build, unpicked from the checkout outwards
KURU had migrated to Magento 2 in 2018 and the build had been failing them ever since, with checkout errors taking sales out of the business daily. Certified Magento developers worked part-time on weekly releases, starting at checkout because that is where the revenue was leaking, then site speed, then the rest. Conversion improved 33% in 2020 versus 2019, and site speed 13.44× in 2020 versus 2018.
KURU Footwear. Maintenance and targeted optimization on Magento 2, with certified developers.
Ghost kitchens added to an ordering platform that kept taking orders
After acquiring part of C3 Company, TGI Fridays needed several virtual brands to live inside one transactional platform without any of them losing its own identity. We redesigned the ordering and corporate platforms, ran a WCAG accessibility audit with manual testing alongside the automated tooling, and re-architected a backend whose data silos kept inventory, pricing and orders from agreeing.
TGI Fridays. UX, accessibility audit and backend modernization, with semantic HTML and keyboard navigation built into the design system.
Five countries in five months, on top of an existing VTEX
AB InBev’s direct-to-consumer strategy needed one app across markets that disagreed about logistics, currencies, catalogs and stock. TaDa Delivery is React Native, integrated with the VTEX they already ran, synchronising inventory, pricing, promotions and orders in real time across all of them.
AB InBev. Product development and an embedded team. React Native, Node.js and VTEX.

What changes when money is already moving through it

A store stops being a project the day it takes its first order. Everything below applies to a system you inherit, and to one you built yourself the week after it launches.

The baseline moves while you work on it
On a store that is still selling, requirements keep arriving and the code keeps changing underneath the work. There is rarely a stable version to migrate from, which is a planning problem before it is a technical one. Plans that assume a frozen starting point are the ones that slip.
Checkout comes first, and the reason is arithmetic
When a store has problems everywhere, the order of the fixes decides how much it costs to fix. Errors in the transaction flow take money out of the business every hour they survive, so they come before speed and before anything cosmetic, however visible the rest is.
You inherit whoever built it last
This work almost always begins inside someone else’s decisions: a migration done in a hurry, extensions that were never meant to be permanent, data split across systems that no longer agree. Reading that well is most of the first month, and skipping it is what turns a fix into a second broken build.

Questions we get before the first call

Do you build stores from scratch, or only work on existing ones?
Both. Some clients come to us without an ecommerce operation at all and we build it; more often the system already exists and the work is migrating it, stabilising it, or keeping it fast as it grows. The published cases here are all of the second kind, which says more about which projects became case studies than about what the team does.
Which platforms do you actually work on?
Adobe Commerce, VTEX and Shopify, the three the team holds certifications on. Naming a longer list would mean naming platforms we have never had to fix at three in the morning. On the storefront and the app side the work is React and React Native.
Can you migrate a store without taking it down?
Yes, and Lentesplus is the published example: a high-traffic store selling across four countries moved from Magento Open Source 1.9 to Adobe Commerce Cloud while it stayed in active use, with new requirements arriving throughout. What that costs is planning rather than downtime: there is no frozen version to work from, so the sequence has to absorb a moving baseline.
What does ongoing work look like?
Weekly releases and daily fixes, with priorities set against revenue rather than against a backlog order. On KURU that meant certified developers working part-time and shipping every week rather than a large team shipping every quarter, starting with the checkout errors that were costing sales every day.
Do you handle accessibility?
Yes, and on TGI Fridays it was audited rather than assumed: automated tooling plus manual testing of how people actually moved through the menu and the checkout, with semantic HTML and keyboard navigation built into the design system so later brands stayed accessible by default.

Commerce systems built, migrated, and kept fast under load.

What we’ve done under real traffic

A live migration off Magento 1.9, across four markets

Two years of a broken build, unpicked from the checkout outwards

Ghost kitchens added to an ordering platform that kept taking orders

Five countries in five months, on top of an existing VTEX

What changes when money is already moving through it

The baseline moves while you work on it

Checkout comes first, and the reason is arithmetic

You inherit whoever built it last