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
•
August 31, 2026
Managed Agents, Not Managed Services
At the end of the last article I said the specs, tests, and agents that built See’s new storefront are now the same infrastructure that runs it, and that this was a story about what happens to “managed services” that deserved its own article.
This is that article.
The loop that runs the site
Here’s what post-launch support looks like on See’s today.
A delivery lead spots a problem. Or a merchandiser does. Or an automated check does. They paste it into Slack: a screen recording, an expected behavior, sometimes just a sentence. From there, an agent takes over. It triages the report against the Functional Specification Documents that are still the source of truth for the site, reproduces the behavior, and files the Jira ticket, correctly categorized, linked to the relevant spec, evidence attached. Then it writes the fix in the right repo and raises a draft PR.
The PR doesn’t arrive naked. It carries the actual test cases linked to that ticket, not a boilerplate checklist everyone ticks without reading, but the specific scenarios QA expects to pass, each one a gate before merge. When the code or the specs change, the Playwright page objects and regression suites regenerate to match. Before a release, an agent reads every ticket and PR in the version, maps the affected areas, and produces the regression plan a QA lead used to spend days assembling by hand.
And the fidelity gates from the build phase never left. Missing elements, broken assets, responsive widths, locale slips: measured checks wired into the pipeline, so a change can’t be “done” until it passes. Humans review exceptions. A named human reviews every merge. That’s the whole loop: automated QA, automated triage, ticket creation, code written right to the PR, with judgment concentrated exactly where it belongs.
Nothing in that paragraph is a roadmap. It’s running.
Why this kills the retainer
Every SI knows what a support retainer really is. Most enterprise retailers pay somewhere between $40K and $250K a month for “managed services,” and the work being done for that money is mostly staff augmentation. Tickets in, tickets out. A rotating cast of mid-level engineers keeping the lights on, and a senior architect on retainer for the weekly steering call. 64labs has always tried to stay out of this mosh pit. We have always believed most clients could and should manage their own site. But while we hear retailers grumble about the cost of managed services, they have never seen a viable alternative beyond hiring a team for themselves and that carries its own risks. So the structure survived as a kind of IT Stockholm Syndrome.
To be clear, this model was never about technical capability. It was about technical recruiting capability. Retailers can’t hire, manage, and retain the engineers required to run a commerce stack, so the SI fills the gap. You were never buying engineering. You were buying access to engineering. Managed services is a cleverly disguised arbitrage.
Watch the loops I described above run for a week and the math of that arbitrage collapses. The tasks that filled the staff-aug queue (bug triage, config changes, test maintenance, integration glue, analytics tagging, minor UI upgrades) are exactly the tasks agents now eat for breakfast. Scope that took eight to ten FTEs in 2024 is delivered by two or three people plus a properly orchestrated agent estate. And the smart retailer immediately asks the obvious question: if agents are doing the work, why am I paying a body-shop margin on bodies?
The billable-hours model doesn’t survive that question. Not five years from now. Now.
Managed agents: pooled, not embedded
So what replaces it? Our answer is a different unit of value entirely. Not managed services - managed agents.
Agents are not a thing you build once. Models improve, vendor stacks shift, platform APIs change. The agent you built in 2026 goes stale by 2027 unless someone maintains it, upgrades it, expands it. What a client buys in a managed-agents relationship is a guarantee: the estate of agents running their business is current, governed, and getting better, maintained by a small number of very good people who know their business and well-integrated into both client and partner technology teams.
Here’s the part that changes the economics. That estate doesn’t have to be rebuilt per client, and it doesn’t need a pod of 10 to operate. The skills our agents run on, the triage runbooks, the QA contracts, the spec-sync workflows, live in a central, shared infrastructure. Every agent session logs whether a skill worked as documented. Those logs cluster into retrospectives that open PRs against the skills themselves. A lesson learned on one client’s build ships to every client’s build. When the dust settles on launch, one person at 64labs can manage that shared infrastructure across the whole client base, making sure our best practices propagate to everyone, automatically.
Pooled infrastructure, centrally maintained, continuously self-improving. That’s why the cost reduction isn’t 20%. It’s a 50-80%. The headline fees will look small next to the old retainers. The capability behind them will be larger than anything the retainer ever bought. Your current partner is either adapting to a more demanding, lower-revenue world or going bankrupt. You should be eager to speed that outcome up one way or another.
Tough for the old boys. A leap for everyone else.
None of this is comfortable if your business depends on staff-aug volume. The firms whose commerce practices rest on post-launch managed services - and that’s most of them, giants and boutiques alike - are holding a book of business whose unit economics are about to look indefensible. The test any CIO should apply to a partner this year: are they trying to make themselves redundant, or indispensable? Tribal knowledge in their heads, agents on their infrastructure billed back to you: that’s the old model defending itself. Skills codified, agents shipped into your environment, knowledge transfer as an explicit obligation: that’s a partner you can do business with.
But for customers, this is not a story about loss. The amount of work an enterprise actually wants done is about to explode: the experimentation programs, personalization variants, taxonomy cleanups, and data passes nobody could ever justify at old prices. The cost per unit of work is collapsing, so the volume of commissioned work goes up, not down. The retailers who thrive will be the ones who either find the right managed-agents partner or are big enough to build the practice themselves: a small agent-operations team, a governed estate, and a partner measured on their team’s autonomous capability rather than monthly burn.
64labs is a Salesforce Commerce Cloud partner and Storefront Next launch partner. If you’re paying a managed-services retainer and wondering what a managed-agents model would look like on your stack, ask us. We’ll show you the loop running on a real production site.
5 min read
•
August 27, 2026
The See's Candies Storefront Next Build: From PWA Kit to Production
See's Candies is live on Storefront Next.
That makes it the first production storefront running on Salesforce's new composable framework, and the build behind it tells a more interesting story than the launch itself. 64labs started the migration before Salesforce had even finished the codebase, working alongside the platform team in real time while most partners were still waiting for GA.
The result: three production storefronts (Retail, Fundraising, and Volume Sales), over 1,800 pull requests, and a set of lessons about Storefront Next that don't exist anywhere in the documentation yet.
Three Sites
See's Candies isn't a single storefront. It runs three, each with its own checkout logic, promotional model, and operational workflow. Fundraising has a completely separate business rules engine. Volume Sales uses pricing structures that don't exist in standard B2C Commerce.
That complexity is what makes this build worth paying attention to. A single-storefront Storefront Next launch would prove the framework works. A three-storefront launch with this level of business logic proves it works at enterprise scale.
Dima Shevchuk, product owner on the project, said the multi-site architecture surfaced problems that a simpler build never would have. "Single MRT versus multiple MRT rendered some of the previously working redirects impossible," he explained. "When you have the same relative path for each site with different target URLs."
The Migration Path
Migrating from PWA Kit to Storefront Next isn't a full rewrite. The SFCC backend and API layer stay mostly the same. What changes is the frontend architecture: server-side rendering, React Server Components, a different routing model, different state management. For a team with composable SFCC experience, the learning curve is real but manageable. For a team without it, this is where projects tend to stall.
64labs had 12 PWA Kit builds in production before starting the See's migration. The code doesn't carry over one-to-one, but the architectural instincts do: where SCAPI behaves unpredictably under load, which patterns hold up long-term, and which ones become technical debt.
A significant portion of the 1,800+ pull requests went toward third-party integrations, the part of Storefront Next delivery that conference talks tend to skip over. DynamicYield for personalization, Bazaarvoice for reviews, Amplience for content management, Cybersource for payments, Experian for address validation, and OneTrust for consent. Every one of those had to be rebuilt for the new architecture.
Helen Martin, who oversaw delivery and integration strategy, said DynamicYield was manageable because the team had recently built it on PWA Kit. "We had a good line in the sand as to what we needed to build in SFN, so most of it was migratable," she said. "The challenge was the minor 20% of edge cases that only surface when you're using it in anger with a lot of UAT data coming through." The team built the integration with active consent from the start, so OneTrust was already handled before See's turned it on in production.
The Phased Rollout
See's didn't go live all at once. The team launched Fundraising first, then Volume Sales, then Retail.
Dima explained the reasoning: "FR and VS are low-traffic B2B sites, very simple, low risk. Retail is much more complex and more things can break. So we proved stability on FR and VS first."
Each storefront got its own go/no-go, its own regression pass, and its own production hardening cycle. The phased approach let the team validate the deployment pipeline, redirect strategy, and analytics parity on lower-risk sites before putting the highest-traffic storefront through a live cutover.
Where the Speed Came From
The most surprising insight from the build might be where the time savings actually came from.
When asked where the speed came from, Dima didn't point to the framework. His take was that Storefront Next itself mattered less than the AI harness and delivery workflows 64labs had built over the six months before the See's project kicked off. The tooling they walked in with on day one did more for velocity than the platform switch.
In other words, the framework is better, but the acceleration came from the operating model 64labs built around it: AI harnesses, task structures designed for LLMs, and delivery workflows that took roughly a year to develop. The framework provides the foundation. The workflow around it is what compresses the timeline.
What This Means Ahead of Dreamforce
Dreamforce 2026 kicks off September 15 in San Francisco, and Storefront Next will be one of the biggest talking points on the commerce side. Most SIs will be presenting their plans for the platform. 64labs will have already shipped it.
The See's build offers something that slides and roadmaps can't: proof that Storefront Next holds up when real enterprise complexity, real third-party integrations, and real revenue are on the line. Whether other partners can get there without the same head start is an open question, but the platform has cleared its first production test.
See's Candies is live. The framework works. And the most useful lessons from the build are the ones Salesforce couldn't have documented, because they only come from being first.
5 min read
•
June 23, 2026
Storefront Next is an AI-First Commerce Architecture
There is a version of the AI conversation that has become painfully familiar in enterprise commerce. Teams say they are "using AI." Developers mention Claude Code. Someone demos a copy generator. A few hours get saved here and there. Meanwhile, CIOs and CTOs look at the org chart, look at the budget, and ask the only question that matters: if AI is real, why are the benefits mostly showing up as a better day for staff instead of a better business for the enterprise?
That is the right question. And it is exactly why Storefront Next on Salesforce matters.
The argument for Storefront Next is not that it gives your team a shinier storefront framework. The argument is that Salesforce is finally putting an AI-first commerce architecture on the table, one that can change how the stack is assembled, how work is divided, how much manual tuning is required, and where automation can compound over time.
For technical leaders, that distinction matters. AI that helps an individual contributor write code faster is useful. AI that changes the architecture so the enterprise can reduce complexity, automate repetitive commerce work, and create a cleaner path to measurable operating leverage is strategic.
The real problem: AI has been too personal, not operational
Most enterprise teams are seeing narrow AI gains. Developers use copilots. Analysts summarize documents faster. Merchandisers generate a few drafts instead of writing from scratch. Those are legitimate improvements, but they are local improvements. They help individuals. They do not automatically rewire the system the business runs on.
That is why so many executives are underwhelmed. If the only visible effect of AI is that smart people can do the same job a little faster, then the enterprise has not captured much value. The headcount line stays the same. Delivery models stay the same. Support models stay the same. Vendor sprawl stays the same. The organization ends up paying for AI, talking about AI, and still operating largely the same way.
That is not transformation. That is productivity theater.
Storefront Next changes the argument
Storefront Next is a full-stack React framework for B2C Commerce that combines server-side rendering with client-side navigation in a managed Salesforce architecture. Salesforce is positioning it as an AI-first storefront and has tied that positioning directly to faster implementation, AI-powered developer tooling, and simpler launch patterns.
That matters because architecture determines how far AI can go.
An inconsistent, over-customized commerce stack is hard for humans to maintain and hard for AI tools to reason about. A more opinionated, convention-driven stack is easier to scaffold, easier to extend, easier to support, and easier to automate. That means Storefront Next is not just another frontend option. It is a better substrate for AI-enabled delivery and AI-enabled operations.
This is the part technical executives should care about. The value is not only in what AI does today. The value is in choosing a platform shape that will allow more of tomorrow's build, support, merchandising, and optimization work to be delegated to AI systems with less friction.
Cimulate is the bigger story than most teams realize
Salesforce's acquisition of Cimulate is one of the clearest signals that this is not a superficial AI story. Cimulate combines real shopper behavior with simulated shopper journeys to infer intent and improve search, discovery, and recommendations in ways that go beyond traditional keyword and rules-based systems.
That should get the attention of any CIO or CTO who has watched teams spend years tuning search synonyms, patching low-conversion discovery flows, and layering manual merchandising rules on top of brittle relevance models. Cimulate's approach is built around understanding intent through both real and synthetic commerce behavior, which means the engine gets stronger not only from what happened, but from what likely could happen across millions of modeled sessions.
That is enterprise value.
Why? Because discovery is one of the most labor-intensive and under-optimized layers in commerce. Teams pour human time into relevance tuning, catalog shaping, landing page curation, campaign setup, and recommendation logic. If Salesforce can productize Cimulate inside the Storefront Next and Agentforce Commerce motion, that opens the door to automating a category of work that has historically required constant expert intervention.
That is the shift skeptical leaders should focus on. This is not AI as a sidecar. This is AI moving toward ownership of an economically meaningful layer of commerce operations.
The architecture is the real signal
Put those two moves together, the AI-first storefront and an intent-aware discovery engine, and the pattern is clear. Salesforce is not bolting AI onto the edges of commerce. It is reshaping the substrate so that more of the work can eventually be automated rather than hand-tuned.
For technical leaders, that reframes the evaluation. The question is no longer whether AI is useful. It is whether your architecture is built to let AI compound. Choosing a platform shape that AI systems can reason about, extend, and operate is the first real decision, and it is the one that determines how much value everything after it can capture.