ROI² is the framework behind our Centra headless work: five layers, all sliced and named the same way. It makes a headless build predictable to scope and safe to work on with AI agents, and it already runs our Shopify builds too.
A developer (or agent) who has never opened one of our Centra storefronts can clone the repository, run a single command, and have a working store talking to Centra and Storyblok.
That command checks and installs the tooling, project, verifies it, and then says what to do next. No credential is emailed or pasted into a chat window. Nobody works through a setup guide, because there is nothing left in the guide to work through.
That is the part people notice first, and it is the least interesting part of what we built. It only works because of the four other layers sitting behind it.
Centra headless is our core engineering practice, and ROI² is our storefront framework for headless commerce builds and the delivery system wrapped around it. It has five layers.
What makes it work is that every layer is cut along the same lines. A change requested in a workshop can be traced by name through the requirement, the design, the component, the test and the release.
In this market, an accelerator usually means a head start on layer three. Centra now publishes its own open-source Storefront Accelerator, which it describes as a boilerplate shop built on its Storefront API, and it is a well-made reference implementation.
That project is good for the ecosystem, and it was missing for years. We read the current public repository when we ran our own comparison, and on the commerce mechanics the two are equivalent. Anyone claiming a commerce-capability gap in either direction is overstating it.
The difference is scope. A reference implementation proves the plumbing works. It does not agree what gets built before anyone estimates it, turn a brand's look into a working storefront, trade in four markets at four different prices, or answer the phone at two in the morning.
ROI² also carries a documented catalogue of storefront features. Everything in it has been implemented in at least one client project, verified in production and documented with its business value. The catalogue covers:
Two of these save a surprising amount of time on their own. Full ecommerce tracking, forwarded into Klaviyo, needs a tracking account ID and a plugin switched on. No code and no deployment. And structured data ships as standard, so products appear in search results with price and stock from day one rather than as a later SEO project.
The commercial effect shows up first in scoping. A brand planning a build can point at what already exists and already works, instead of describing it from scratch and paying to discover what it costs. The parts that are truly bespoke become obvious immediately.
The alignment is the whole point, and it took years rather than months.
In most builds, requirements are written in one vocabulary, designs in a second and code in a third. Translating between them is exactly where scope changes without anyone deciding to change it. A component gets built slightly differently from how it was drawn. A requirement turns out to mean two things. The budget moves, and nobody can point at the moment it moved.
Removing those translation steps is how a project skips most of the solutioning discussion and arrives at a predictable, scoped outcome. It also makes the design system portable. A brand that is not ready for a redesign can keep the site it has: our designers map the existing look onto the design tokens, and the build reflects it. A redesign can be implemented quickly, because the thing being designed and the thing being built are the same named parts.
ROI² is also maintained as one shared product rather than a per-project fork. A fix made for one brand is released as a new package version and picked up by the others, so no client pays to build the same foundation twice.
Very little of this is specific to Centra. The requirements checklist is organised by business domain, not by API, and the design system describes a storefront rather than a platform. Only the commerce packages know which commerce API they are talking to, and that is a deliberately thin slice of the whole.
So ROI² now runs our Shopify headless builds as well as our Centra ones, with the same design system, named blocks, test approach and support model. For a brand, the platform decision no longer drags the entire delivery approach behind it. With a working store standing in days, headless no longer has to be sold as the slow, expensive option next to a themed platform.
An increasing share of development work is done with AI assistance, and the foundation decides whether that work is safe.
A raw model is an engine. It becomes a useful agent once it is wrapped in the material nobody puts in a demo: rules files, tools, sandboxes, guardrails, tests and context. An agent dropped into an undocumented codebase will guess, and guessing in a checkout is expensive. Most failures come down to missing context, and the dangerous version does not look like a failure at all, because the code looks right and passes the basic tests.
So ROI² carries a machine-readable description of itself, plus AI instructions scoped to the folders they govern: an assistant editing the checkout reads the checkout rules, not generic advice. The model generates, the harness verifies, and a person sets the standard.
One of our engineers was an open sceptic about AI-assisted development until he tried it properly on an ROI² project. "I tell it to mimic all our patterns, we always have the same setup, tests, structure, and it holds to it like it is on rails." He was using the same model as before, inside a much better foundation.
We saw the same with design systems: few saw the point of weeks spent on tokens and component rules, until the teams that did it started building faster. Foundations are boring right up until they become the reason a team is fast. AI amplifies whatever engineering culture it lands in. Strong standards make it much faster. A mess gets scaled.
A framework covers the repeatable part of a storefront, which is most of it, but never the whole job. Integrations with an ERP, a PIM or a warehouse are still designed against the specific systems in front of us. Custom business logic is still written for the brand that needs it. Replatform architecture decisions and data migration are still projects in their own right.
The same is true of design. A design system gives a brand consistency and speed, but it doesn't give it a point of view. Deciding what the storefront should feel like, and which moments should be bespoke, is work for a designer who understands the brand. What ROI² does is make sure nobody spends judgement on the foundation, so it gets spent on the parts of a project that are actually unique.
Starting from a reference implementation means starting with a working cart, then building the other four layers around it. That is the part that decides whether a project lands on budget.
ROI² arrives with all five already in place, proven across live brands, documented for people and for agents, and running on Centra and Shopify headless alike.
If you are weighing up a Centra or Shopify headless build, a replatform, or a redesign on a storefront you already have, we are happy to walk through the requirements checklist with you and show what is already built before anything gets estimated.
