The leader in multi-site composable storefronts for top-tier brands delivered in six months

The

leader

in

multi-site

Composable

Storefronts

for

top-tier

brands

delivered in

six

months

The reality of technology change in ecommerce is that there is never a good time. Anything major needs to avoid disrupting the business and distracting everyone’s attention away from the business of selling products. So a modern technology project just cannot take 18 months of everyone’s time and potentially fail or cost twice what your so-called partner said it would. You need short projects, minimal timeline risk, and a partner who will do what they say they will do, when they said they would do it for the price they told you it would cost. But how is that going to be possible? Everyone is different, everyone has bodies buried in their SFCC build, everyone has other work to do. Well that’s what a partner should be there for - to take on the risk and work out ways to make the project as predictable and painless as possible while leaving you with a great outcome you can support yourselves if you wish.  That’s what 64labs does.

‍

The Reality Check: Timelines and Hidden Delays

You want this over with. And so does everyone else. But on average if you use traditional system integrators a composable storefront project can take  9 months for hybrid, and more like 18 for a full build. 

Here’s how the competition typically breaks down (without naming names):

• “Standard” big consultancies: Projects take 12–18 months. If they can convince you to do hybrid they will. More money for them. Longer engagement for them. Phase 2s and Change Orders for them. No value for you.
  
  
• Boutique agencies: 9–12 months is often quoted, especially for complex multi-country or multi-brand work. There are some good companies in this bracket. But velocity requires experience and if this is their first rodeo they are going to make friends with the dirt a few times during your project before they get back on the horse. That takes time.
  
  
• Unassisted Internal team: This is the riskiest and likely longest project pathway of all. It is not that your team is’;t great. But they have a day job. They cannot commit full time to a composable project, they cannot give it their full attention. And they have minimal experience of a composable build and what can derail these kinds of projects. They are good people. They want to do the project. But on their own they will make mistakes that will cost you months or lead the project into the weeds.
  
  

‍

What 64Labs Actually Delivers

This is where it gets different. With 64Labs, the average timeline for a full composable storefront is 16–26 weeks from kickoff to launch. That’s four to six months: not a number picked from thin air, but what 10 real projects have taken.

How does it break down?

• Sprint 0 (Discovery, Accelerator application, Architecture and CMS): 4 weeks, focused on sharp requirements, practical, production-grade engineering by our top team, and actionable project plans. You are going to see the site working end to end, potentially in multiple locales, with new CMS integrated, at least with standard tooling on board. Cost: $185k
  
  
• Scopotype: 8 weeks of hands-on engineering, core commerce logic, problem solving, custom code rebuilds, 3P re-integrations, CMS rollout, and the plan to finish the site with your team or partner. Cost: $385k
  
  
• Build to Launch: 4 to 12 weeks, flexing with the messiness of multi-country or multi brand legacy integrations, the volume of migration work, the urgency of launch, the capacity and capability of your team. Cost: $100k to $300k
  
  
• Launch: 4 weeks prepping for launch for two weeks with final QA, planning and executing the production cutover or AB split, and full post-launch support for two weeks post launch. Cost: $65k
  
  

No long-winded up-front planning, no boomerang back to the drawing board at every misstep—just real delivery. If we miscalculate, we just get on and do the work required to catch up. No change orders, no problem.

‍

How Much Should You Pay?

Here’s a painful reality: some named agencies will pitch you composable storefronts with sticker prices starting at $1.5 million, with the meter running for every slightly off-the-beaten-path integration and every dashboard tweak. 

• Big consultancies: Commonly north of $1 million before post-launch support and "phase two" fees.
  
  
• Boutiques: $750,000–$1.1 million is typical, with heavy change-orders and phase 2s as the project gets real.
  
  
• Low-cost players: Sub-$500,000 builds exist, but usually with rigid templates, reduced flexibility, and less robust engineering.
  
  

At 64Labs, the cost is clear and tied to real deliverables. Sprint 0, Scopotype, Build to Launch, and Launch are all included and laid out from the start. With just $600,000–$850,000 for a ready-to-scale composable storefront there is no nickel and diming and no “gotcha” line items. 

Plus, if you want us in your corner post-launch, you’re looking at $60,000–$100,000 per month, tailored to what you actually need.

‍

Why the Gap? What Drives Time and Price

The gap is real, and most of it comes down to three things:

• Integration and Migration Complexity: More systems, clunkier legacy platforms, and higher custom logic add time and cost everywhere. You can either find a partner who will shoulder that risk - the 64labs model. Or you can find a partner that sees complexity and uncertainty as a way to squeeze more money from the project.
  
  
• Team Decisiveness: The fewer drawn-out meetings and “maybe next sprint” calls, the quicker things go. For SIs who rely on billable hours post-launch, and who are licking their lips at a phase 2, there is no hurry, no need to get things done, no need to make difficult decisions early.
  
  
• Expectation Management: Big players pad timelines for margin and risk; template shops skip real discovery, do less custom work, and shove more to “phase two.” With 64labs you get a fixed price for a well understood piece of work and an experienced team who have seen your problems before.
  
  

Project Breakdown at a Glance

‍

‍

Bottom Line

If you are serious about going composable, you want your storefront built around a playbook that has actually shipped multiple times, without the runarounds or sticker shock. The true cost is not just the fee; it’s the lost opportunity when launch dates slip and value never lands. At 64Labs, “on time” and “on budget” are not wishful thinking; they are the standard, backed up by actual reference projects. Ask us for names.

‍

If you’ve spent time anywhere near the world of Salesforce Commerce Cloud, you’ve probably run into “SiteGenesis.” Maybe it’s the bones of your storefront, maybe it’s the thing your team curses after tough deployment weekends, or maybe it’s just the old world of ecommerce development and merchandising you’re being told to leave behind. So what is SiteGenesis, why did it get popular, and why is almost every forward-looking brand moving on.

‍

The Origin Story

SiteGenesis was first rolled out back in the Demandware era (think pre-2016, before Salesforce acquired them) as the primary reference architecture for building e-commerce storefronts on what’s now called Salesforce B2C Commerce Cloud. The whole idea was simple enough: give brands a ready-made, production-grade starter kit for online stores—full of checkout, cart, product, and customer management baked in. Developers could clone, customize, and get to market faster than starting from scratch.

Back then, SiteGenesis was a breath of fresh air. It standardized how you built and extended an enterprise storefront and shipped with:

• Templates for every major shopping journey (home, category, product pages, cart, checkout)
  
  
• Core features like promotions, order management, customer accounts, and wish lists
  
  
• Extensible “cartridge” modules so you could plug in payments, shipping, or integrations with third-party tools
  
  
• “Pipelines” and later JavaScript controllers for customizing storefront logic
  
  

The Architecture: What’s Under the Hood?

SiteGenesis is a monolithic, server-rendered architecture. It’s split into two flavors: the older “Pipeline” version, and the newer JavaScript Controllers (SGJC) version. Either way, everything flows through the same core concepts:

• Controllers: Server-side scripts (JavaScript or proprietary pipeline scripts) that respond to customer actions—like adding to cart or searching.
  
  
• Cartridges: Modular code packages letting you drop in new features, integrations, or styling.
  
  
• Models and Views: Separates business logic from presentation, but with everything tightly coupled; no clean, modern APIs here.
  
  
• Templates and ISML: Custom template language creating the HTML shoppers actually see in their browser.
  
  
• Business Manager Hooks: Everything configurable from Salesforce’s Business Manager, with preferences for responsive design, visual effects, shipping, and more.
  
  

It’s “all in one box” development—quick for getting started, but not so great at keeping up with today’s front-end expectations.

‍

The Good, the Bad, and the Legacy

Why So Many Brands Used It

• Speed to Launch: Out-of-the-box templates meant you could get online fast, especially before mobile-first design was critical. You could tell a SG site from the home page though. A lot of retailers didn;t really change a lot.
  
  
• Rich Core Features: Promotions, loyalty, catalog tools, and deep integration specs from the jump.
  
  
• Customizable (to a Point): Cartridges gave some flexibility, and the community spawned tons of code snippets and quick wins.
  
  

What Dragged It Down

• Mobile Was an Afterthought: The first versions of SiteGenesis were barely responsive; the second generation didn’t bake in mobile best practices either.
  
  
• Monolithic, Not Modular: Updates were painful, and major changes risked breaking everything because of tightly coupled code.
  
  
• Performance Plateaus: Compared to modern frameworks, SiteGenesis sites often lag behind on loading speed and optimization, which hurts conversion and search rankings.
  
  
• Maintenance Over Innovation: Salesforce stopped releasing new features for SiteGenesis years ago. It’s stable, it still works, but it’s stale. You maintain and patch on SiteGen; you don’t innovate. It’s like a favorite Teddy Bear from your childhood.  There’s a lot of love gone into that thing even if its ears are held together with duct tape.

Why Are Teams Moving Off SiteGenesis?

By the time Salesforce launched Storefront Reference Architecture (SFRA) in 2018, it was clear that SiteGenesis was stuck in the past. SFRA brought a genuinely modular, mobile-first foundation to SFCC, and since then composable storefront options have pushed things even further. Salesforce has officially stopped active development on SiteGenesis—no new features, just essential security and bug fixes. If your site still runs on SiteGenesis, you’re running tech recognized as “legacy” by its own vendor.

‍

Should You Care About SiteGenesis Now?

Let’s put it plainly:

• If you’re still on SiteGenesis: It’s time to plan your replatform or upgrade. New business requirements - especially flexible, mobile, or API-first experiences - aren’t a good fit here anymore.
• If someone is telling you to start a new project on SiteGenesis, politely call Social Services. It’s a cry for help.
• If someone is telling you to upgrade to SFRA from SiteGenesis, ask yourself why. All innovation and support from Salesforce is now (finally) focused on headless, and composable storefronts. You could make this case for SFRA in 2023. But in 2025 are they trying to sell you SFRA today  and then composable in 2027, when maybe they know how to build with it. Don’t fall for it.
  
  

Final Takeaway

SiteGenesis is the foundation hundreds of major retailers built on. It did its job for years, but it’s now a museum piece in the world of digital commerce. If you’re serious about speed, innovation, or mobile, the smart move is to modernize. The future isn’t in the air tonight for SiteGenesis - it’s already completely Phil Collins’d its way out of the equation and is about to become a land of confusion (we could carry on…).

If you want honest advice on what to do next, or need help planning your exit from aging legacy tech, let’s talk.

Walk into almost any ecommerce company today and you will find a design team huddled around Figma. They love it. Marketing loves it too. Screens fly by, campaigns come alive, and new layouts get approved in hours instead of weeks. It feels like creativity finally has a proper home.

Then you wander over to the developers and the mood shifts. They roll their eyes at yet another handoff link. They mutter about inconsistent components and impossible timelines. For them, Figma is less of a revolution and more of a headache.

Why such a divide? And more importantly, how can ecommerce leaders bridge it?

‍

Why Marketers Swear by Figma

For marketing and design teams, Figma represents freedom. It is cloud based, easy to share, and allows real-time collaboration. No more static PDFs, no more emailing zip files back and forth, no more endless rounds of “final_v12.” A merchandiser can jump into a file, tweak a banner, and get buy-in from a creative director before a long lunch.

The pace of ecommerce campaigns demands this speed. Black Friday promotions, seasonal launches, and last-minute product pushes all benefit from a tool that makes iteration frictionless. Figma delivers that in spades.

‍

Why Developers Feel the Pain

Developers, on the other hand, live in a world of constraints. Their job is not just to make things look pretty but to make them work across devices, browsers, and code frameworks. What looks effortless in Figma often requires hours of engineering to recreate.

Marketing teams sometimes assume that if a design exists in Figma, it is already “almost done.” In reality, it might ignore accessibility standards, performance budgets, or responsive breakpoints. Developers inherit the frustration of explaining why a button cannot float exactly where the designer placed it without breaking the grid on mobile.

The resentment builds because developers feel like the tool encourages over-promising. Marketing gets attached to pixel perfect visions that collapse under the weight of real code.

‍

How to Fix the Divide

The answer is not to ditch Figma. It is too powerful (and too useful) a tool to ignore. The fix is to align how it is used.

The best ecommerce teams set clear rules for handoff. They negotiate and build shared design systems that developers help create, so the components in Figma actually match what exists in code. They involve developers earlier in the design cycle, not just at the end. When developers help shape the options, they can steer marketing toward designs that will actually ship fast. There is some sacrifice some of the time. A structured approach to design sounds like something a designer would want - but to get the bargain right with developers they have to do the work and turn a set of potential variations into a system which has limitations. Otherwise the design system is achieving nothing.

Some brands go further and integrate Figma directly into their component libraries. That way a change to a design element in Figma links to the exact code component developers will use. The result is less rework, less resentment, and more campaigns that launch on time.

‍

The Bigger Picture

At its core, the Figma divide is not about tools. It is about empathy. Marketers want speed and flexibility. Developers want stability and quality. Both are right. Both are necessary. The brands that will thrive and achieve actual rather than pretend agility are the ones that do the hard yards of recognizing the tension between the two crafts and turn it into collaboration (or at least a negotiation) instead of conflict.

So yes, marketing teams will keep bragging about how Figma saved the day. Developers will keep groaning when they see another unbuildable mockup. But with the right process in place, both sides can get what they want: campaigns that move fast and sites that do not break in the process.

Because in ecommerce, speed matters. But so does reliability. Figma can give you both if you use it to bridge teams instead of divide them.

‍

If you want honest advice about how to implement a design system effectively, we can help. We have built multiple composable projects where the design system bargain was central to the success of the work we did. We know the pitfalls. We know how to negotiate around them. If you want to upgrade how you do design on your site to a more modern collaborative truly agile approach, talk to 64labs.

‍