Originally published December 2023. Rewritten July 2026 — the original said everything and told you nothing, so I started over.
Why This Post Needed Redoing
The first version of this article was accurate and almost entirely useless. It said VTEX was scalable, flexible, omnichannel, and future-proof. So does every platform’s homepage. Nothing in it would have helped anyone decide anything.
I have spent the time since building on this platform — payment connectors, invoicing, catalog integrations, the unglamorous middle layer where architectural decisions stop being slideware and start being your Tuesday. So here is the version I would actually give someone who asked, including the parts that do not flatter the platform.
What VTEX Is, Structurally
VTEX is a multi-tenant, cloud-native commerce platform founded in Brazil in 2000 and listed on the NYSE since 2021. Twenty-five years in, it runs more than 3,000 active online stores for over 2,100 customers across 44 countries.
But the single most consequential fact about VTEX is one the original version of this post never mentioned: the pricing is transaction-based. The bulk of VTEX’s subscription revenue is a take rate — a percentage of the order value flowing through the platform, taxes and shipping included. Your bill is a function of your GMV.
That single design choice explains almost everything else. It is why VTEX invests heavily in conversion and fulfillment features rather than seat licences. It is why their incentives genuinely align with yours during a growth year. And it is why the finance conversation about VTEX is completely different from the one you have about a platform with a flat annual fee. Model it before you sign, not after your first Black Friday.
The Number That Tells You Who It Is For
Roughly 89% of VTEX’s GMV comes from customers doing more than ten million dollars a year on the platform. That figure is disclosed in their own filings, and it has been climbing.
Compare the numbers from around the time I first wrote this post against the most recent ones, and a strategy comes into focus:
Fewer customers, fewer active stores, more countries, and a larger share of revenue concentrated in the biggest accounts. That is not decline. That is a company that stopped chasing the long tail and went after global enterprise retail instead.
Which is enormously useful information if you are evaluating the platform. It tells you where the roadmap attention goes, whose problems get solved first, and roughly where you sit in the queue.
What Genuinely Works
- Multi-tenancy with sales channels. This is the real differentiator. One catalog, many storefronts, with pricing, inventory, and payment configuration varying per channel. If you run several brands or several countries, this saves you from the architecture you would otherwise have to build and then maintain forever.
- The seller and marketplace model. VTEX treats marketplace operation as a first-class concern rather than a plugin. Seller networks, order routing across sellers, capacity management per seller. Very few platforms in this tier take that seriously.
- A properly modelled order lifecycle. The OMS has real states, real transitions, and real hooks. When you need to intervene between authorization and invoicing, there is somewhere sensible to stand.
- Composable without being assembly-required. You can go headless with your storefront and keep the commerce engine intact. That middle path is underrated, and it is the reason most VTEX projects ship.
What Is Not in the Brochure
None of these are dealbreakers. All of them are things I wish someone had told me before the first sprint.
- The build pipeline has opinions about your toolchain. The platform will pin dependency versions and inject its own resolutions during builds. You will eventually spend an afternoon working out why your local build and the platform build disagree, and the answer will be that the platform quietly decided for you.
- Master Data v1 and v2 are two different products wearing one name. Different capabilities, different validation behaviour, different constraints. You will hit the seam between them, usually while migrating something, usually at the worst time. Know which one you are on before you design around it.
- Documentation quality varies sharply by module. Mature areas are well covered. Newer or narrower ones send you to community threads and trial and error. The announcements feed is the closest thing to a reliable changelog, and it is worth reading weekly.
- Some operations still route through support tickets. This is genuinely improving — 2026 alone moved sales channel creation into the Admin and surfaced order custom data in the interface. But you will still occasionally find that the fix for your problem is an email, not an API call.
- Headless does not mean unconstrained. Decoupling the front end is real, but the storefront frameworks carry their own conventions. You are trading one set of constraints for a different, usually better set. Not for no constraints.
So Who Should Actually Pick It
Strong fit: multi-brand or multi-country retail, operations with genuine marketplace ambitions, businesses with meaningful physical retail to integrate, and anyone whose fulfillment logic is complicated enough that the OMS is doing real work. A LATAM footprint remains a particularly strong argument, since the platform’s depth in that region is not matched by its competitors.
Probably wrong fit: single-brand direct-to-consumer businesses well under the enterprise threshold, teams that want full ownership of the entire stack, and anyone who needs a bill that does not move when sales do. None of that makes VTEX bad. It makes it aimed elsewhere, and the numbers above say so plainly.
The Honest Conclusion
VTEX is important in eCommerce. It processes enormous volume, it solves multi-brand and marketplace problems that genuinely are hard, and it has spent twenty-five years accumulating the kind of operational depth that cannot be shortcut.
But important and correct-for-you are different questions, and the first version of this post conflated them. A platform earns its place in your architecture by fitting the shape of your problem, not by appearing on analyst quadrants. If your problem is one catalog, one country, one brand, there are simpler tools and you should use them. If your problem is forty storefronts across nine markets with sellers and stores and a fulfillment graph that makes people wince — that is what this thing was built for, and it is very good at it.
Company figures above are drawn from VTEX’s public filings. Platform behaviour described here reflects my own experience building on it, and the platform moves quickly enough that some of it will age — check the announcements feed before relying on any specific detail.
No responses yet