| Architectural model |
Templates and pages managed within the VTEX admin panel. |
Native blocks configured via Site Editor, with VTEX IO apps. |
Headless storefront, with decoupled front-end in React/Next.js |
| Main focus |
Quickly publish pages within the standard VTEX template. |
Balance between editing agility and native components. |
Performance, deep customization, and modern architecture. |
| Customization method |
Limited to the templates and options available in the CMS. |
Configurable blocks, with VTEX IO apps for specific rules. |
Open source React/Next.js code, with front-end freedom. |
| content management |
VTEX legacy CMS, with direct page editing. |
Site Editor, with blocks editable by the content team. |
VTEX CMS integrated into the project, with preview and publishing workflow. |
| Development and deployment workflow |
Changes made directly in the production environment |
Publishing via isolated workspaces before production. |
Proprietary deployment pipeline, with testing before each release. |
| Integration with VTEX IO applications |
Limited |
Native — built on top of VTEX IO itself. |
Through VTEX APIs and services, without relying on the same app base. |
| Performance potential |
It depends on the configuration and templates used. |
Well, with native platform optimizations. |
Tall, with architecture designed from the outset for Core Web Vitals. |
| Front-end flexibility |
Low — restricted to existing templates |
Medium — native blocks plus custom apps |
Alta — decoupled and fully customizable front-end |
| Most suitable scenario |
Stores still operating under the legacy model, currently under evaluation. |
Operations that prioritize editing agility with custom-built apps. |
Projects that prioritize performance, front-end freedom, and evolution. |