AI Enabled Storefront
SFCC Storefront Next
Faster performance, smoother integrations, and a front-end built to last. Our approach helps brands stay flexible and ahead of change.
Proven expertise in Composable
64labs built the first SFCC PWA at Duluth and have launched 10 enterprise-grade Composable Storefronts since.
Go faster, reap the rewards
We are commited to replatforming, migrating and launching multi-site storefronts in 16-26 weeks
Performance-Obsessed
Lightning-fast storefronts are empowered by built-in testing at every level. From pull requests to builds we drive speed and ROI.
Proficiency in Headless CMS
The CMS part of your build is a critical driver of business value. But the partner you choose is as important as the CMS.
Saving months of Development time with the 64labs Accelerator
The 64labs Accelerator provides a ready-to-use foundation for your Storefront Next build, featuring prebuilt UX patterns, state management, and essential commerce flows. It includes connectors for CMS, search, and payments, along with a reference architecture and infrastructure templates that integrate seamlessly into your stack. This approach reduces unknowns and rework, compressing a typical 9-month launch timeline into just 4-5 months.
The Process
Our Proven Path to Composable Commerce Success
Explore our step-by-step process — from Sprint Ø to Launch. And see how 64labs brings complex ecommerce builds to life with efficiency, clarity, and proven results.
Technologies matter
We carefully select technologies to use in Composable Storefront to ensure top-notch scalability, performance and future-proofness
Not Sure Where to Start?
Find Out If You’re Ready for Composable
Before investing in Composable Replatforming, it’s crucial to understand how your tech stack, workflows, and team will adapt. Our free Composable Readiness Assessment gives you a clear roadmap — minimizing risk and accelerating delivery.
FAQ
Everything You Need to Know About SFCC Composable Storefront
Yes. 64labs alone has built 12 sites now for major e-commerce brands. It works well. It's fast. We've built out NextJS sites too. They work. They are fast.
The question really is whether the partners and teams trying to implement composable are waiting for Salesforce to solve every use case for them before they feel comfortable building composable sites. It's harder than getting some certifications and throwing the work over the wall to a disciplined but unimaginative offshore team.
Composable will always set challenges for engineers and functional architects. Salesforce is a great platform because it's so flexible. But that comes at the price of complexity and you have to know what you are doing to engineer composable solutions on Salesforce.
No. There is no logical reason to do a hybrid launch of composable storefront. It is not technically easier - in fact it is harder and more complex than a full composable build particularly for larger customers. If you are multi-realm, multi-country, don't even think about hybrid.
In ROI terms it seems logical - this is where the customers are in the upper funnel, right. But in reality customers will switch from PWA to SiteGen multiple times on a journey to purchase and every time they do you are reloading a page, bridging a session and giving a customer a moment to wonder if they really want to keep going.
And even if that all works, you have to find the energy to finish the job and do Checkout within a year or so. Don't do it!
Yes. And no.
Yes post-launch. No during the implementation phase.
If you have multiple advanced-level React developers with years of experience in composable builds then your team could be a capable partner to 64labs in the critical phases of the project. But (statistically) you probably don't. So normally we engage your lead developer or architect for the first 12 weeks of a project. They get to see everything we do. But that guy is learning more than contributing. Their job is going to be to help us train the rest of the gang in the final “Build to Launch” phase of the project.
If the bulk of your team are full-stack SFCC developers who have played around with React and don't really know what they don't know, you should be identifying those who will in future focus on the front-end and those who will focus on the back-end. With some training from 64labs, and participation in the latter stages of the project, your best full-stack SFCC guys can handle steady-state on your new composable build. And frankly the back-end guys will be doing pretty much what they have always done but with a realistic opportunity to find time to pay off a ton of technical debt.
Large enough to deliver as fast as humanly possible and small enough to keep people from slowing each other down.
Our development team typically consists of a Technical Architect, 2-3 Front-end developers, 1 SFCC Full Stack Developer and 2 QA engineers supported by Business Analyst, Project Manager, and Designer.
However, the team structure may change depending on the project phase -- we're not charging clients for idle time. For example, you don't need as many people on Sprint Ø or Launch phase, so we tailor the team composition depending on what the project needs more in any given moment.
We start even before the project kicks off.
First of all, the base all 64labs projects start from — our Composable Accelerator — is end-to-end tested on multiple levels, and has several quality control layers built in: from linters, and PR-level testing though shift-left practices, automated testing on pre-merge, and then manual and automated UI and Integration testing suites on staging environments.
As the development advances, we are adding more levels of testing including all custom features and integrations, as well as dataLayer, SEO, and Accessibility testing.
Second, every 64labs team has multiple builds under their belt. Everyone on your project has seen the challenges you will face and dealt with (most of) them.
Third, we bring soft skills too. From the management of meetings and sprints, to the checkins with internal stakeholders, 64labs takes responsibility for getting the information and support the project needs. If we make mistakes we solve them, we don;t write up change orders. If we think we can help your team succeed we will do it, never mind what the SOW says is our role and yours.
You don’t just get production-ready code -- performance-optimized, covered with automated testing, and supported by a scalable design system your team can own - you get a live storefront, launched by a team with deep knowledge of Salesforce’s Managed Runtime infrastructure and committed to the commercial success of the project. 64labs is known as a launch company, which means we stay with you through go-live. Whether it’s a “big bang” release or a phased traffic-split cutover, we ensure your composable storefront isn’t just built, it’s successfully launched and delivering value from day one.
Moving to a composable architecture unlocks several key benefits across performance, flexibility, and scalability:
- Faster Performance – Modern composable storefronts are lighter and more optimized than monolithic setups, resulting in faster load times and smoother customer experiences. The older your Salesforce build, the more benefits you are likely to reap here.The ROI for your project lives here. Better performance = lower bounce = greater conversions = more revenue.
- Agility & Flexibility – You can swap in best-of-breed tools (CMS, search, personalization, etc.) without being tied to a single vendor’s limitations or relying on a cartridge built by someone else five years ago. You get to work with specialist vendors and implement their technology for your specific needs. You also get the IT and Merchant team out of each other’s docket. That frees a lot of time on both sides.
- Omnichannel Readiness – Content and commerce experiences can be delivered consistently across web, mobile, apps, in-store devices, and future channels.
- Marketer Empowerment – A headless CMS gives business users a more intuitive, user-friendly way to create and publish content without relying heavily on developers.
- Future-Proof Foundation – With composable, you can evolve your stack incrementally as new technologies emerge, avoiding disruptive “big bang” replatforms.
In short, going composable positions your digital commerce experience for greater speed, adaptability, and long-term resilience.
No, you don’t need to migrate to SFRA before adopting a composable approach. While SFRA provides a more modern foundation compared to SiteGenesis, going composable is not dependent on it. At 64labs, we assess your current SFCC setup and “under-the-hood” architecture to determine the best path forward. In many cases, we can layer a composable storefront on top of your existing environment without requiring a full SFRA upgrade first.
That said, if you’re still on SiteGenesis, we’ll highlight any limitations that could impact speed, flexibility, or long-term maintainability - and advise on what scale of changes you should make to enable the composable roadmap. But this is rarely a barrier to your project.
Usually, no. A Composable storefront decouples the front end, so you can keep SFCC as your system of record and integrate via SCAPI/OCAPI while we modernize the experience layer first.
Our approach
- Start incremental: Stand up the composable storefront and custom SCAPI endpoints if needed; integrate with your existing SFCC services and data.
- Harden what exists: With live experience under your belt, add caching, edge/CDN strategies, and optimize key flows (catalog, cart, checkout) over time.
- Evolve selectively: Revisit backend pieces post-project only where there’s clear ROI - eg, any remaining brittle customizations, performance bottlenecks, gaps in APIs, or where external services (search, CMS, PIM, pricing, personalization) deliver additional value.
- Use a “strangler” pattern: Replace or carve out services one by one without a risky “big bang” rewrite.
When a backend change is worth it
- Critical flows can’t meet performance/SLA targets
- Heavy Business Manager customizations block agility
- Data model or integration debt slows every change
- You’re adopting best-of-breed tools that need cleaner APIs
Bottom line: switch the storefront first, prove value fast, and only rebuild backend components that you can see are holding you back.
We recommend keeping UX/UI changes limited during the composable storefront build. Large redesigns can slow down the process and make it harder to clearly measure the architectural and performance improvements from the shift to composable.
That said, we do encourage making smaller, high-value updates - such as applying best practices or tackling long-standing business requests - that won’t disrupt the build. This approach ensures you get the benefits of composable quickly, while still addressing meaningful UX/UI enhancements. The key here is the ability of a design and project team to put a bargain together that recognizes and tackles urgent needs and quick valuable wins, but accepts that the new technology makes the more prosaic upgrades to a design much simpler post-launch.
Yes. A composable storefront can be rolled out gradually using A/B or phased approaches. Many teams start by exposing a percentage of traffic (for example, 5% or 10%) to the new storefront while the majority of users continue on the legacy SFCC experience. This allows you to monitor performance, validate integrations, and collect user feedback before scaling further.
With this approach, you can:
- Compare performance (speed, conversion, engagement) between legacy and composable experiences.
- Mitigate risk by rolling out incrementally rather than all at once.
- Refine the experience based on real customer behavior before full adoption.
This approach requires CDN based routing that can perform real-time routing decisions.
No. Our accelerator is a starting framework built from best practices and experience across all our past projects. It gives us a fast launch point so we can focus quickly on your customizations and third-party integrations.
The code is entirely yours - you own it outright. There are no monthly or yearly licensing fees, and you can upgrade or extend it at any time to support your roadmap and business needs.
Some teams like to keep us around as experts in the new technology on one of our Momentum offerings. But most of our customers are excited to take the helm of their new stack and the upgrades they might want to make are in their hands. In any event, we are always available to help when asked.
Going headless delivers clear advantages for business and marketing teams:
- Revenue – Through lower bounce, higher engagement, improved conversions and add-to-carts, your composable project can be paid off and returning on your investment within 3 months.
- Faster Campaign Execution – Marketers can create, schedule, and publish content without waiting on development cycles, reducing time-to-market.
- Greater Flexibility – Content is managed once and published everywhere - across web, mobile, apps, and emerging channels—without duplicating effort.
- Improved Personalization – Headless architectures integrate easily with best-of-breed tools for personalization, targeting, and A/B testing, giving teams more control over the customer journey.
- Scalability – As your business grows or channels expand, your content delivery scales without rework or disruption.
- Future-Proofing – You’re no longer locked into a single vendor’s roadmap - marketing can adopt new tools and channels as they emerge.
In short, headless empowers your marketing team with more agility, independence, and consistency - so they can deliver better experiences, faster. And it generates incremental revenue, which in the end is the whole point of everything we do.
SEO remains a top priority during the transition. When we implement a headless storefront, we:
- Retain all existing URL structures so your current rankings and backlinks stay intact.
- Apply up-to-date structured data and schema markup to ensure search engines can index and interpret your site correctly.
- Collaborate closely with your team or SEO agency to align on strategy and make the handoff smooth.
This approach minimizes SEO risk while giving you the long-term performance and flexibility benefits of a composable storefront.
Accuracy of your analytics setup is a core part of our process. During the project we:
- Discover (Sprint Ø) – Document your current analytics structure so we have a clear baseline.
- Pixels & Tracking – Review and update all pixels to the latest versions, ensuring proper configuration
- Collaboration – Work directly with your team or agency on the setup and any needed adjustments.
- Implementation – Develop and integrate the required code, tags, data layer, and pixels as part of the build.
- QA & UAT – Validate the entire implementation in quality assurance and user acceptance testing alongside your team.
This structured approach ensures your analytics remain accurate, reliable, and aligned with your business needs throughout the transition.
Based on our experience, the challenges usually aren’t with the technology itself but with how the transition is managed. The most common issues include:
- Leadership focus – Teams sometimes treat replatforming as an opportunity to redesign or add features. Successful projects keep leadership aligned on the primary goal: launching composable first and building on that foundation.
- Third-party integrations – Dependencies on external vendors can cause delays if they’re not responsive or prepared to support composable setups.
- Parallel requests – Internal teams often request unrelated changes during replatforming, which can create scope creep and slow progress.
- Competing priorities – Large internal projects or dependencies may block the composable initiative if not planned around.
- Skills gap – A lack of engineering resources with React and composable expertise can make execution harder, because it creates unnecessary defensiveness among the team.
At 64labs, we surface these risks early in the Sprint Ø phase so they can be addressed before they become blockers.
We’re not here to replace a successful incumbent. We also know you don’t want to pay your SI to learn composable from scratch or repeat mistakes others have already made. Instead, 64labs’ role is to accelerate their success:
- Early phases – We move quickly and autonomously, implementing our accelerator and handling the initial architectural setup. But the process is transparent and open to your SI to observe and assist.
- Collaboration – We often work side by side with your SI, helping them get up to speed on composable concepts and the hidden complexities of the architecture.
- Knowledge transfer – As the project progresses, we train your SI team, assign them work, and provide peer reviews and pull requests to build confidence.
- Enablement – We aim to train at least one lead FE engineer who can serve as an internal trainer for others going forward.
- Flexibility – Every client relationship is a little different, and we adapt our engagement model to your specific needs.
This approach ensures your SI stays engaged and grows in composable expertise, while you get the speed and confidence of our proven accelerator and experience.
No. Our approach minimizes risk to your production environment. We use your existing backend and extend it only where necessary through custom SCAPI endpoints. These endpoints and supporting code can be rolled out to staging and production safely, without impacting your live site or current workflows.
This means your production environment remains stable, while we introduce the integrations and capabilities needed for a composable storefront.
No, in most cases you don’t need to purchase or set up an additional Realm. We build the composable storefront on top of your existing SFCC backend, extending it where needed through custom SCAPI endpoints. This approach allows new code to be deployed to staging and production environments without disrupting your live site or requiring extra Realm licenses.
If there are unique circumstances that suggest a second Realm would be beneficial (for example, large-scale parallel development or complex regional rollouts), we’ll flag that early in the assessment and advise accordingly.
Perspectives worth sharing
5 min read
•
May 29, 2026
Storefront Next and the End of Expensive SFCC Ownership
For years, Salesforce Commerce Cloud has had a cost problem; and it was never just licensing.
The real cost lived in the ecosystem around it: custom templating languages, hard-to-find specialists, slow iteration cycles, and a persistent dependency on external partners for even modest changes. Teams didn’t just pay for SFCC, they paid to operate it.
Storefront Next changes that equation in a fundamental way.
By moving to a modern, standard frontend stack - React, composable architecture, familiar tooling - you eliminate one of the biggest hidden taxes in the system: specialization. No more hunting for niche ISML experts. No more translating between modern frontend thinking and legacy templating constraints. You can hire from the broader market, use proven patterns, and move at the speed your team is actually capable of.
That alone lowers total cost of ownership. But it’s just the starting point.
What really changes is how companies choose to operate.
Two Paths To Tread
Once the barrier of “expensive to change” disappears, companies will likely split into two operational camps.
The first group will optimize for steady state. They want the site to run cleanly, predictably, and with minimal intervention. Their goal is a near-zero backlog, a very small team, and a system that largely takes care of itself. Updates are incremental. Automation handles the routine. Human involvement is reserved for exceptions.
For these teams, Storefront Next is about cost control. It allows them to finally run SFCC themselves as a stable, low-maintenance platform instead of an ongoing project.
The second group sees the opposite opportunity. If the cost of change drops, why not do more?
More experimentation. More landing pages. More personalization. More campaigns. More integration across systems. The same team, or an even smaller one, can now produce significantly more output because they are no longer constrained by platform friction.
This is where Storefront Next can be more about growth than cost.
And of course in practice, most companies should do both.
Stabilize, Then Expand
This is the pattern we recommend for dealing with the confusing world of AI. Don’t be carried away in the hurly burly of innovation. Go up the learning curve in stages. Iterate and learn over time. Keep moving forward but don’t go faster than your organization (probably still quite slow) can handle.
First, get to a solid steady state. Reduce the noise around support. Eliminate the backlog. Automate the obvious operational work. Bring the cost of “keeping the lights on” as close to zero as possible. This is a business process question as well as a development and marketing one. Do what you do better and quicker and more automatically. Stop doing things that humans require but machines don’t - about 50% of the meetings you do each day?
Then take that recovered time and reinvest it.
Not into rebuilding what you already have or adding fancy so called AI-native tools - but into extracting more value from the stack you’re already paying for.
That means connecting the pieces of your stack that have historically operated in silos:
CMS feeding landing page generation
Personalization driving dynamic content decisions
Search influencing merchandising and discovery
Campaign tooling tied directly into experience delivery
Individually, these systems are powerful. Connected, they become multipliers. (You already knew all this but there wasn’t time or mental energy to actually achieve the achievable)
And once connected, all these newly exploited existing systems become candidates for automation. Without spending an extra penny on an AI enablement platform.
Automation Before AI
There’s a misconception that AI transformation starts with buying an AI product.
It doesn’t. It mustn’t.
It starts with getting your stack into a state where it can actually support automation. Clean data flows. Defined workflows. Clear system boundaries. Reliable integrations.
If you automate your current workflows and your current workflows are designed around human frailties then you will just have automated mediocrity. What a waste. Get the most out of what you already have. Organize yourselves to be efficient, and let automation take care of as much of the resulting work burden as “humanly” possible.
Only then does AI have something to work with.
What happens next is not a switch you flip, it’s a gradual process. You automate pieces of the workflow. Then you introduce AI to optimize, generate, or orchestrate within those workflows. Over time, more of what was previously human-gated becomes system-driven.
But none of that works if your frontend is slow, rigid, or dependent on scarce skills.
This is where Storefront Next quietly becomes strategic.
Why SFCC Becomes More Valuable
SFCC has always been flexible. That was never the issue.
The issue was that most teams couldn’t fully use that flexibility. The cost of implementation, the friction of the frontend, and the dependency on specialized skills meant that much of the platform’s capability remained theoretical.
Storefront Next changes that.
When teams can actually build, iterate, and integrate without friction, SFCC’s flexibility turns into a real advantage. It becomes the center of a composable, connected, and increasingly automated commerce stack.
And importantly, it becomes a platform that can evolve.
Not through large, expensive replatforming efforts, but through continuous, incremental improvement.
That’s the shift.
Lower cost of ownership is the entry point. Operational leverage is the outcome. And long-term adaptability is the real payoff.
If you’re already on SFCC, the decision is straightforward. The question isn’t whether Storefront Next is worth it - it’s whether you want to keep paying for constraints that no longer need to exist.
5 min read
•
May 26, 2026
Storefront Next Launched Today. Here’s What Actually Matters.
Today Salesforce Commerce Cloud officially rolled out Storefront Next, and if you glanced at the announcement headlines, you’d think this is just another frontend framework release.It’s not.This is Salesforce making a very direct play for net-new logos - specifically the brands that, over the last five years, defaulted to Shopify Plus instead of even considering SFCC. Think digitally mature mid-market and enterprise brands currently sitting on Magento, HCL, Oracle Commerce, or SAP Hybris, who want to modernize but don’t want a three-year re-platforming science project.That’s the real audience.
Who This Is Actually For
Salesforce isn’t trying to convince existing SFCC customers to rip and replace. (Though if you are on SiteGen still, you absolutely should). They’re trying to remove the biggest historical objection to adopting SFCC in the first place:“It’s too slow, too expensive, and too complex to get live.”Shopify won that argument for five years by making speed to market and consistency their product. Storefront Next is Salesforce’s response. It’s their attempt to say: we can move just as fast, but without ditching the enterprise-grade flexibility when and where you need it. And that matters, because the buyers evaluating platforms today are not the same as they were five years ago. They’re more technical, more impatient, and far less tolerant of long SI-driven timelines.
The AI Layer Is Not a Feature. It’s the Point
The most important part of this launch isn’t the framework itself. It’s the AI enablement baked into how it’s meant to be built, extended, and maintained.This is where most people will underestimate what’s happening. Storefront Next is being positioned as “AI-ready,” but that undersells it. What Salesforce is really doing is laying the groundwork for how commerce teams will operate over the next 12–24 months:
- Faster component generation
- AI-assisted integration work
- Automated testing and QA workflows
- Smarter merchandising and content operations
- Reduced reliance on large engineering teams for day-to-day changes
But here’s the part that needs to be said clearly: this transition will go slower than most people expect - if you do it right. AI doesn’t magically fix bad architecture or poor implementation decisions. If anything, it amplifies them. What Storefront Next does is give you a clean enough foundation that AI tools can actually be effective and useful to you. Without that, you’re just layering automation on top of technical debt. Automated incoherence is still incoherence.
Speed to Build Is Finally Competitive
Historically, SFCC implementations have been measured in quarters (or years), not weeks. That changes. With Storefront Next, prebuilt patterns, composable architecture, and modern tooling have the potential in the right hands to dramatically compress a build timeline. You’re no longer starting from scratch, and you’re no longer fighting the platform to make it do standard things or all the cool things you saw in the demo.If you pair that with AI-assisted development workflows, you can realistically stand up a production-ready storefront much faster than legacy SFCC builds. Probably faster than a couple of your release cycles on your current platform. Maybe it changes the math for brands sitting on Oracle, HCL, Magento, or Hybris. The transition path into SFCC is materially easier and more cost-effective than it was even a year ago. What used to look like a heavy, multi-phase transformation is now something you can approach in a far more controlled, incremental way - without giving up the flexibility and warm-blanket enterprisiness SFCC is known for.That combination, speed plus flexibility, simply wasn’t real before.
Why the SI You Choose Matters More Than Ever
This is where most brands will get it wrong. Storefront Next makes it easier to build. It also makes it easier to build poorly. In fact, because things move faster, bad decisions compound faster too. Overconfident developers who don’t really know composable architecture will get cozy and complacent in the warm embrace of AI tooling.If your SI treats this like a traditional SFCC project, you’ll end up with:
- Over-engineered components. I hate the word slop but I guess this is the technical term for that.
- Misaligned data models. The meat of a build is still how everything is integrated. AI never understands that as well as it needs to. If you can’t help it understand, it will guess.
- AI tools that generate inconsistent or unusable output. Or as Claude might frame the problem - humans who don’t really know where AIs strength and weaknesses are.
- A codebase that’s technically modern but operationally fragile. “Yay, it's React.” But it performs worse than SiteGen.
On the other hand, if you approach this the right way - with a team that understands both composable architecture and how AI-assisted workflows actually function - you get something very different:
- A clean, extensible frontend
- Predictable development patterns AI can work with
- Faster onboarding for internal teams
- Lower long-term support costs
Where 64labs Fits in This Shift
This is exactly where we see our role at 64labs evolving. Not as a traditional system integrator, but as a guide through what is becoming an AI-assisted re-platforming cycle.The technology is only part of the equation. The harder problem - and the more valuable one - is translating real business requirements into code in a way that AI tools can extend, not fight against. That means designing architectures that are structured, consistent, and AI-compatible from day one - sometimes in the face of a business that wants to hang on to the old jumbled workflows and habits that they know. That means helping brands migrate off Oracle, HCL, Magento, and similar platforms in a way that reduces both cost and risk. It means accepting that these migration paths are well worn, not that rocky and should not be costing seven figures ever. It means using AI to accelerate delivery where it outperforms humans (working nights and weekends) without sacrificing long-term maintainability (humans not having to work nights and weekends).
Building storefronts that are not just modern, but adaptable to what’s coming next
The reality is, SFCC has always been powerful. What’s changed is that it’s now becoming manageable in a way it wasn’t a year ago - both in terms of speed and cost - if it’s implemented correctly.Our role is to act as the sherpa through that transition: helping teams make the right decisions early, avoid the traps that AI will amplify, and ultimately deliver better commerce experiences faster.
This Is a Foundation, Not a Finish Line
The biggest mistake would be to treat Storefront Next as the end goal.It’s not.It’s the starting point for a different way of building and running commerce experiences - one where AI is embedded into every layer of the workflow, not bolted on afterward.This next 12 months is going to be mad. The stench of oversold bullshit is going to be overwhelming. But some basic things are likely to be consistently true throughout.
- AI-driven storefront personalization will evolve quickly.
- Internal commerce teams will more and more on AI copilots
- Development cycles will compress as far as human capacity will allow them to.
- The gap will widen between teams that built their current stack out in 2026 for this shift and those that made do with what was fine in 2021.
And the companies that benefit from the madness won’t be the ones who adopted something (anything!) the fastest.They’ll be the ones who adapted to the chaos from a position of foundational strength. Storefront Next is a valid part of that foundation for present and future SFCC customers alike.
5 min read
•
May 15, 2026
Why Your Storefront Next Migration Should Start with Parity
Storefront Next is real. So is the hype. The mistake retailers can make right now is confusing Salesforce's ambitions for the platform with the actual operating model required to deliver it successfully.
Salesforce is right about the broad direction. Storefront Next is meant to lower implementation time and cost, compress integration effort, and make modern enterprise storefront architecture easier to launch and manage. In its partner materials, Salesforce positions Storefront Next as quick to launch, easy to manage, enterprise-ready, AI-first, and capable of reducing medium implementation timelines from 20 weeks to 12 and costs from $600K to $350K. It also claims that 70% of migration code can be AI-generated and that teams can get to UAT faster with AI-assisted migration tooling.
The important thing to understand is that these claims are not wrong. But they are incomplete.
At 64labs, the conclusion reached after a year of working through this technology is straightforward: the value is real, the acceleration is real, and the AI gains are real, but only when the project is commissioned and executed in a way that reduces noise instead of adding to it. That is why the first phase in a Storefront Next engagement should not be reinvention. It should be Build to Parity.
Build to Parity First
Retailers are often tempted to treat a storefront migration as the ideal moment to redesign the site, rework the experience model, swap key vendors, and revisit old architectural debates. That instinct is understandable. It is also one of the fastest ways to make AI less useful and migration more chaotic.
Build to Parity means something simple: take the site as it exists today and make it Storefront Next first. Move the current storefront onto the new architecture. Preserve the experience. Preserve the working business logic. Preserve the vendors unless there is a compelling reason not to. Only after parity is achieved should a retailer seriously evaluate redesigns, major UX changes, or meaningful vendor transitions.
This message is harder to land when parity sounds like a six-month holding pattern. Smart clients do not want to be told to postpone every improvement while they sit through a long migration program. That is a reasonable reaction. But the conversation changes when Build to Parity is not a six-month ask. It is a four-week ask to get from kickoff to UAT on the right scope. At that point, it becomes a very realistic decision for serious teams: contain the noise, prove the migration path, and earn the right to make bigger changes from a stable Storefront Next foundation.
That sequencing matters because AI migration works best when the problem is constrained. Salesforce's own materials point to AI-assisted migration, code comparison, and validation as the path to getting 70% of the way there quickly and reaching UAT faster. That is directionally correct. But AI does not do its best work when the target is moving. The more simultaneous change a project introduces (new design system, new business rules, new vendors, new data flows, new user journeys) the more noise the model has to absorb, and the less reliable the output becomes.
In other words, AI is at its best when it is asked to migrate. It is much worse when it is asked to migrate, redesign, replatform, and reinvent all at once.
The 70% Claim Is Real, In the Right Hands
One of the more eye-catching numbers in Salesforce's Storefront Next materials is the idea that 70% of migration code can be AI-generated. That lands well with customers, and in this case it should. The claim is not fantasy. 64labs has found it to be broadly correct.
But that does not mean any team with an out-of-the-box AI tool will immediately achieve it. The difference is not whether Salesforce's tooling is useful. It is. Salesforce is clearly investing in an AI-first developer toolkit, a unified B2C CLI for agents, agent skills, and workflows meant to speed onboarding, prototyping, and storefront changes. The issue is that those tools still sit inside a learning curve, and most organizations are much earlier on that curve than they think.
Getting to that 70% outcome requires experienced composable engineers who know how to prompt well, how to create harnesses for large language models to operate within, how to compare outputs against a known-good baseline, and how to structure review and testing so the code becomes production-ready rather than merely plausible. That is the part that is easy to miss from the slideware. The tool is not the operating model. The tool still requires an operating model.
At 64labs, that operating model took roughly twelve months to develop. It was not built in theory. It was built through repeated passes at real Storefront Next delivery, including work done before Salesforce had fully completed the codebase. It was built by iterating through different multi-week development processes and forcing the team to answer uncomfortable questions: What level of task granularity gives AI enough direction without creating overhead? What testing approach catches the characteristic failure modes early? What scoping method keeps migration noise low enough for the model to remain effective? Which accelerators are truly reusable and upgrade-safe, and which are just temporary shortcuts?
Those answers were not obvious on the first pass. On the first pass, it was easy to conclude that AI itself was the problem. Many teams will have exactly that experience. They will get halfway there, watch the outputs become inconsistent, and decide the tooling is overhyped. In most cases, the problem is not the existence of the tool. The problem is that the team is still learning how to use it.
64labs just happens to be about twelve months ahead on that learning curve.
Why Customers Should Commission the Project Differently
This matters because medium, multi-site Storefront Next projects still have real complexity. Salesforce's own implementation goals put a medium program at 12 weeks and $350K in the new model, even after the projected gains from AI and the new framework. Storefront Next also explicitly targets customers with multi-site and multi-brand needs, enterprise scale requirements, and extensibility demands.
So the right way to commission the work is not to ask a general question like, "Can AI make this faster?" The right question is, "How do we structure the engagement so AI can do the work it is actually good at?"
The best answer usually looks like this:
Phase 1: Build to Parity. Move the current site into Storefront Next with as little additional noise as possible.
Phase 2: Stabilize and prove the workflow. Get through testing, UAT, launch readiness, and production hardening.
Phase 3: Optimize. Revisit redesigns, vendor shifts, UX improvements, and the broader roadmap once the migration foundation is stable.
That is also how 64labs can credibly stand behind a promise of four weeks from kickoff to UAT for the right slice of work. That promise is not based on pretending a medium multi-site transformation can be compressed into one month with no tradeoffs. It is based on knowing that when the first phase is tightly scoped around parity, the AI workflow can be made reliable enough to move very quickly.
This is the part internal teams often underestimate. They assume the challenge is mostly development capacity. It is not. It is delivery design. It is knowing how to scope the first release, what to leave alone, how to constrain the model, how to review code efficiently, and how to avoid drowning the migration in "while we are here" decisions.
That is why most customers should not try to make their internal team invent this process on day one.
Your Team Should Be Involved, But Not Alone
None of this means the internal team should be excluded. Quite the opposite. Building a Storefront Next program well should be a team effort. The retailer's people should participate in architecture, review, QA, and workflow design. Knowledge should transfer during the project. The goal should be for the customer to own the system after launch and not need to retain 64labs for long.
But there is a major difference between participating in a proven process and paying to invent one.
As Salesforce itself signals, the role of the partner is changing. The value is becoming more consultative, more specialized, and more tied to industry experience and repeatable accelerators rather than just raw implementation labor. That is exactly the right frame for Storefront Next. A strong partner is not there to replace the customer team. A strong partner is there to help the customer avoid spending twelve months rediscovering what already had to be learned the hard way.
That is the real ROI case. Not just a faster launch, but a cleaner path to getting actual value from AI before executive skepticism sets in. Build Storefront Next badly and the platform will look expensive, the migration will feel harder than promised, and the AI story will start to sound like marketing. Build it well and the result is different: a modern storefront foundation, a team that understands how to work with the new tooling, and a much stronger chance of realizing the cost and speed improvements Salesforce is betting on.
Storefront Next is not a reason to throw away discipline. It is a reason to become more disciplined about what changes now, what changes later, and who should lead the learning curve. The retailers that get the best results will not be the ones that ask AI to do everything at once. They will be the ones that reduce noise, build to parity first, and learn with people who have already gone through the hard part several times over.