If you're standing up a Sana Commerce store and you ask "who builds it?", the honest answer is that the question has two answers, and most Sana projects only staff for one of them. Sana's partner ecosystem is built around ERP implementation partners: the firms that already live inside your Business Central, S/4HANA, NAV, or F&O instance. They are the natural choice to wire Sana to the ERP, because that is the work they do every day. But "wire Sana to the ERP" and "build a storefront that converts" are not the same job, and the second one rarely comes with the first.
We do Sana work as a web, design, and development agency. We are not an ERP VAR, and we don't pretend to be. That distinction is the whole point of this essay, because understanding it is how you avoid the most common way a Sana project quietly disappoints: an accurate integration bolted to a storefront nobody designed.
Why the gap exists (it's structural, not lazy)
Sana sells through a partner channel, and that channel is dominated by ERP partners for a good reason. Sana's core promise is ERP-integrated commerce: real-time pricing, inventory, and customer logic served straight from the ERP. Selling and delivering that promise requires partners who can speak fluently to the ERP side. So Sana's incentives, its certifications, and its co-selling motions all orient around ERP implementers. That is sound business. It is also the source of the gap.
Because here is the thing about ERP implementation firms: their center of gravity is correctness, not conversion. They are excellent at making the price right, the tax right, the credit-hold logic right, the ship-to rules right. Those are non-negotiable and genuinely hard. But front-end craft (the typography, the responsive layout, the accessibility, the page-speed budget, the merchandising, the checkout friction work) is a different discipline with a different talent pool. Asking an ERP partner to also be a top-tier front-end studio is like asking your structural engineer to also be your interior designer. Some firms have both. Most don't, and there's no shame in that.
The two jobs on a Sana project
It helps to name the two jobs plainly, because once you see them as separate, the staffing decision answers itself.
Job one is the integration. Mapping web users to ERP customer records, validating that pricing and ATP and credit logic come back correct for every customer segment, handling the customer-master mess that always surfaces, building add-ons inside Sana's own framework so they survive the quarterly upgrades. This is ERP-partner territory. If you try to do it with a pure web shop that has never touched your ERP, you will feel it.
Job two is the storefront. Information architecture, visual design, the front-end build, accessibility to WCAG, Core Web Vitals, merchandising, the conversion path, content. This is agency territory. If you try to do it with a pure ERP shop, you'll get a store that's correct and forgettable. Correct matters. Forgettable costs you revenue every day it's live.
Who owns what: the clean division
The projects that go well are the ones where the line between these two jobs is drawn explicitly on day one. Here is the division we run, and the one we'd recommend even on projects we're not part of.
The ERP partner owns
- The ERP connector and integration health. Real-time pricing, inventory, ATP, credit holds, payment terms, customer-specific catalogs. The data has to be right; that's their charter.
- The customer-master relationship. Web user to ERP customer mapping, ship-to vs bill-to, duplicate cleanup, the data-quality work that nobody scopes and everybody hits.
- ERP-side business logic and add-ons that touch ERP data. Built on Sana's add-on framework so they survive upgrades.
- The ERP environment, test data, and the validation that pricing returns correctly per segment.
The web agency owns
- Information architecture and UX. Navigation, search, faceted browse, the authenticated-buyer experience, the path from landing to reorder.
- Visual design and the front-end build. The Sana theme, responsive layout, design system, brand expression inside Sana's templating.
- Accessibility and performance. WCAG conformance, keyboard and screen-reader paths, Core Web Vitals, the page-speed budget that an ERP-fed storefront makes harder, not easier.
- Conversion and merchandising. Product-detail layout, checkout friction reduction, requisition and reorder flows, content, the things that move the number.
- Front-end add-ons and presentation logic. Built on Sana's framework, but concerned with how the store looks and behaves, not what the ERP says.
Shared, and worth a standing meeting
- The seam between ERP data and presentation. How a credit hold renders, how an out-of-stock line behaves at checkout, how customer-specific catalogs drive navigation. Neither side owns this alone, and it's where projects break when nobody's watching it.
- The upgrade path. Both sides write add-ons. Both sides have to keep them upgrade-safe. One quarterly upgrade test plan, not two.
The failure mode when one firm tries to do both
The single most common Sana disappointment we get called in to fix is the all-in-one ERP-partner build: the integration is flawless and the storefront looks like a 2014 admin panel. The pricing is right to the penny. The buyer can't find the product, the mobile layout is broken, the checkout has three avoidable steps, and the accessibility audit fails on the first automated scan. None of that is a knock on the ERP partner. It's the predictable result of asking one discipline to deliver two.
The opposite failure exists too, and it's worse. A pure web agency with no ERP fluency takes the whole project, treats Sana like Shopify, hand-writes integrations outside the add-on framework, and ships something that breaks on the next Sana upgrade and was never returning correct prices for the customers on contract terms. We don't take those projects without an ERP partner on the integration, and you shouldn't hand one out that way either.
The quotable version: an ERP VAR makes the price right; a web agency makes the store sell. A Sana project needs both, and most are only staffed for one.
How to staff it, concretely
If you're running the procurement, the cleanest structure is two contracts with one explicit seam. Your ERP partner (often your existing implementer) owns the integration scope. Your web agency owns the storefront scope. You define the seam (the shared list above) in writing before either starts, and you put both leads in the same weekly standup. That's it. The overhead of two firms is real but small, and it's far cheaper than the rework when a single generalist firm under-delivers on the half it isn't built for.
If you'd rather have one throat to choke, fine, but make the prime contractor the one whose weakness you can most afford. If your ERP is gnarly and your brand is simple, let the ERP partner prime and subcontract design. If your ERP is clean Business Central and your brand and conversion goals are ambitious, let the agency prime and subcontract the connector. Just don't pretend the weak half doesn't exist because one logo is on the invoice.
Where Sana being agency-friendly actually helps
To Sana's credit, the platform doesn't fight the agency role. The theming and add-on model give a front-end team real room to work without touching ERP logic, which is exactly the separation of concerns this division of labor needs. A disciplined agency can own the entire presentation layer and never once put a second source of truth in front of the ERP. That's the architecture working as intended: the ERP stays the system of record, the agency owns the experience, and the two meet at a documented seam.
What this means for buyers
If you only remember one thing: when a Sana partner says they'll "handle the whole thing," ask which half they're actually good at. The ERP integration and the storefront are two crafts. The platform was built assuming both would show up. The partner channel was built assuming the first one would. Mind that gap on purpose, staff for both, and you get what Sana actually promises: an accurate ERP-fed store that people also want to buy from.
We're a Sana-certified web, design, and development agency, and the storefront half is the work we do. If you've got an ERP partner lined up and need the half they don't cover (or you're not sure how to split it), start a conversation. You can also read more about how we work as a Sana Commerce agency, our broader Sana Commerce capabilities, or how Sana compares to BigCommerce if you're still choosing a platform.