Comarch e-Sklep vs Endora Commerce — which one to pick for B2B

If your company runs on Comarch ERP (Optima, XL, Altum or XT), then Comarch e-Sklep holds a card no other vendor can beat. Product records, stock levels, prices, customer-specific discounts, credit limits and sales documents travel into the shop straight from the system you actually run the business in, without a single line of integration code. Nobody has to settle who is responsible when stock levels drift apart, because the ERP and the shop come from the same manufacturer and share one support line. On top of that: Comarch cloud hosting, backups, updates and an SSL certificate in the subscription. The entire operational layer simply stops being your problem.

That is a very strong offer and I want it up front, not buried in a closing paragraph. For a large share of Polish distributors running on Comarch ERP it is the shortest route to a working online sales channel, and there is no point looking any further.

The difference this comparison starts from is the point of origin. Comarch e-Sklep was designed as a sales channel for Comarch ERP. The ERP is the source of truth, and the shop presents what the system lets it present, within the boundaries the manufacturer sets. Endora Commerce went the other way: the buyer is an organization, the price comes from a contract, an order can be the outcome of a negotiation, and the ERP is one of the systems plugged in through an adapter, no matter whose it is. Below I show where that difference stops being theoretical, and where it makes no difference at all.

The short version

If you only read three sentences: pick Comarch e-Sklep when you run on Comarch ERP, your B2B fits the pattern of “regular trading partners buy at their prices from the ERP”, and a single vendor accountable for the whole thing is a value in itself. Pick Endora when business-to-business selling has processes of its own (negotiations, a hierarchy of branches, an unusual order lifecycle, several channels at once), or when you do not want somebody else’s product roadmap deciding what your shop can do. If you have Comarch ERP, a working e-Sklep and nobody is complaining, do not migrate. Read the cost section and come back to the question when the first requirement outside the standard shows up.

What each platform actually is

Comarch e-Sklep

Comarch e-Sklep is a SaaS platform from a Polish manufacturer, sold above all as a companion to Comarch ERP systems. You pay a subscription and the shop runs in the Comarch cloud together with hosting, backups, updates and an SSL certificate. You have no access to the server, the code or the database. You have an admin panel, graphic templates, a visual drag-and-drop editor and a synchronisation mechanism with the ERP.

The platform comes in four variants: Light (up to 50 products), Standard, Enterprise and B2B. The features that matter for wholesale (customer-specific price lists, net prices, multiple logins under one trading partner, multi-currency and an unlimited number of languages) start at the Enterprise variant. The B2B variant adds the Comarch e-Sklep Sync service, which pulls trade documents out of the ERP, plus control over the credit limit and the overdue-payments limit. That distinction matters when you price the project: credit-limit control requires the B2B variant and a running Sync service, not Enterprise alone.

To run e-Sklep and e-Sale on Comarch ERP Optima you also need the Logistyka Basic module (Handel plus Kasa/Bank). It is easy to forget when comparing subscriptions, because it does not appear in the e-Sklep price list. And without it the shop will not start.

e-Sklep B2B and Comarch B2B are not the same product. Comarch sells two different products under confusingly similar names, and it is worth knowing which one you are asking about:

• Comarch e-Sklep B2B: Comarch cloud, data synchronised between the ERP database and the shop database through the e-Sklep Sync service, works with Optima, XL and Altum, selling in both B2B and B2C, integrations with Allegro, eBay and Amazon, newsletter, blog and reviews, one shared warehouse in the presentation layer, modifications limited to the look of the site, 32 languages.
• Comarch B2B: installed on the customer infrastructure with a virtual key, running online directly against the ERP database with no synchronisation process, XL and Altum only, no Optima, B2B only (no retail, no auction sites, no price comparison engines), warehouses presented individually, source code, database and API open to modification, 33 languages. You order it through a Comarch partner, not through a web form.

So if you read somewhere that “the Comarch B2B platform lets you modify the code and the API”, that sentence is about Comarch B2B, not about e-Sklep B2B. And if you run on Optima, Comarch B2B is not available to you at all.

Endora Commerce

Endora Commerce is a B2B platform written in TypeScript: a Fastify backend with MikroORM and Zod contracts, a server-rendered Next.js storefront and a React admin panel. Data in PostgreSQL, cache and queues in Redis, search in Meilisearch. Over 60 modules as standard: from the catalog and price lists to KSeF, product feeds and an AI assistant in the admin panel. The full list of platform features covers the scope.

B2C selling runs on the same installation and the same data model: registering an individual customer quietly creates a one-person organization, so orders, requests for quote, invoices and addresses follow exactly the same path as in B2B. B2C is switched on separately for each sales channel, and a purely wholesale channel simply will not accept that kind of registration.

The delivery model is the opposite of SaaS: you do not pay a subscription, you get a platform rolled out around your processes, with the code in your own Git repository and the data in your own database. The first working prototype takes four weeks, and an average rollout lands in the region of PLN 60-80k, excluding integrations with external systems, which are quoted separately.

Performance

This is a criterion where two things need separating: the infrastructure and the data model.

On infrastructure, Comarch has an operational advantage that cannot be argued away. The shop runs in the manufacturer cloud, updates land on their own, backups happen without you, and nobody calls you at night about a full disk. The subscription buys you out of the entire operational layer, and that is real value, not a marketing line.

Endora renders the storefront on the server in Next.js, with Core Web Vitals targets written straight into the platform requirements (LCP under 2.5 s, INP under 200 ms, CLS under 0.1) and search under 200 ms at the 95th percentile. The target scale is hundreds of thousands of SKUs and hundreds of orders and requests for quote per month on a single VPS: 4 vCPU and 8 GB RAM minimum, 8 vCPU and 16 GB recommended. The demo runs on a catalog of over 120k SKUs, and generating a product feed for 100,000 products produces a 38 MB file with peak memory use under 20 MB, because serialisation is streamed. Those are good numbers, but it is still a server somebody has to monitor, patch and back up.

The data-model difference is the more interesting one. In e-Sklep the shop is not the source of truth but a mirror of the ERP. Product records, prices, discounts and stock arrive by synchronisation, and in the B2B variant trade documents are pulled by the e-Sklep Sync service. There are two consequences and both are worth knowing. First, the catalog performance ceiling is set by how much and how often the ERP can push, and Optima is not a database designed to be queried by a shop. Second, with a large number of trading partners on individual price lists, the volume of data that has to be synchronised so that every logged-in buyer sees their own price grows accordingly.

In Endora the pricing engine works the price out on every request: from the group price list, the individual contract, the quantity break and the time window, with deterministic resolution of overlapping rules. There is no such thing as “the price list has not arrived from the ERP yet”, because the price list lives in the platform. A quote pulled through the API goes through the same engine as the cart, so the two agree to the penny.

A caveat: Comarch e-Sklep has years of rollouts in Polish distribution behind it and thousands of live shops. Endora’s numbers are architectural targets confirmed by tests and the scale of the demo, not a decade of production peak seasons.

Rollout and running cost

This is the criterion where intuition misleads most often, and in both directions.

What exactly you pay Comarch

Two notes. First, the public price list on the e-Sklep site quotes different brackets (Standard from PLN 150, Enterprise from PLN 599, B2B from PLN 899 per month), while the manufacturer price list for Comarch ERP Optima puts e-Sklep B2B in the cloud at from PLN 695 net. The actual rate depends on the ERP system and the contract, so always confirm the number with a partner rather than with an article. Second, the B2B plan is not the whole bill: if you do not already have the Logistyka Basic module, it comes on top of the subscription, and with several seats it multiplies by the number of licences.

What exactly you pay Endora

Three years in numbers

Let us work through two scenarios over 36 months, net, excluding card processing fees (they occur on both sides) and excluding the Comarch ERP subscription itself (if you run Optima you pay it either way).

Scenario A: a company that fits the standard. One Logistyka Basic seat, a bespoke version of a stock template, a KSeF package for 1,500 documents a year.

• e-Sklep B2B: PLN 695 × 36 = PLN 25,020
• Logistyka Basic: PLN 75 × 36 = PLN 2,700
• Partner rollout with a bespoke template: PLN 35,000
• KSeF package: PLN 50 × 36 = PLN 1,800
• Total: PLN 64,520

Endora over the same period: PLN 60-80k of rollout plus PLN 15-30k of infrastructure, so PLN 75,000 – 110,000.

In this scenario Comarch is cheaper and I will say so plainly. The recurring gap is minimal anyway: Comarch comes to PLN 9,840 a year, Endora’s VPS to PLN 5-10k a year. With a difference that small in the running cost, the simple arithmetic will not level out over any reasonable horizon: after five years Scenario A comes to about PLN 84,200 and Endora to PLN 85-130k. If your requirements genuinely fit inside the e-Sklep standard, cost is an argument for Comarch, full stop.

Scenario B: a company that steps outside the standard. Five Logistyka Basic seats, the same template, the same KSeF package, plus a bespoke communication module between the ERP and the B2B platform. Comarch partners price that last item in the region of PLN 50k net.

• e-Sklep B2B: PLN 25,020
• Logistyka Basic ×5: PLN 375 × 36 = PLN 13,500
• Rollout with a template: PLN 35,000
• KSeF package: PLN 1,800
• Bespoke ERP-to-B2B communication module: PLN 50,000
• Total: PLN 125,320

And here the arithmetic flips: PLN 125,320 against PLN 75-110k for Endora over the same period. Bear in mind that on the Endora side the ERP integration is quoted separately and has to be added to that figure.

The conclusion is simple and uncomfortable for both sides: the threshold does not sit in the subscription, it sits in the first requirement outside the standard. As long as you sell what e-Sklep handles out of the box, it is cheaper. From the moment you start commissioning bespoke modules from a partner, a one-off rollout of your own platform stops being the more expensive option. You also stop paying a subscription for something that had to be written anyway.

Ease of extending the platform

This criterion is best tested against concrete tasks rather than declarations.

Three rows from that table deserve expanding.

Order statuses. Comarch e-Sklep has a closed list of system statuses: from “awaiting shop confirmation” through “confirmed” to “fulfilled” and “cancelled”. They are sensibly designed and cover the typical commercial path, but you will not add your own “technical review” or “in production” step. In Endora the statuses and the transitions between them are configurable, and a business event can be attached to every transition.

Custom fields. Here e-Sklep does better than you might expect: order header attributes come as standard in the B2B variant. Endora goes further, because custom fields are added to orders, organizations, customers, categories, products and requests for quote, always as data, with no database migration and no code deployment.

The ceiling on modifications. This is a difference of kind, not of degree. In e-Sklep, modifications end at the look of the site. The manufacturer itself describes the scope of changes as “the appearance of the page”, in contrast to Comarch B2B, where the source code, the database and the API are listed. In Endora the limit is your time and budget, because the code sits in your repository as ordinary TypeScript with Zod contracts.

Comarch, on the other hand, has an advantage that cannot be argued away: platform updates are in the subscription, automatic and never a project. There is no such thing as “migrating to a new e-Sklep version” with a dozen plugins to retest. Endora hands you the code, but development and maintenance are your deployments and your budget.

One thing only works in one direction: the Endora admin panel has an AI assistant. You open the command palette and describe in plain language what should happen. The assistant shows a plan of the changes and executes it once you confirm, within your permissions and with an entry in the audit log.

There is a number behind that, because “fast” on its own means nothing: a less complex module takes 1-3 days in Endora, a larger one up to a week. That excludes integrations with an ERP, WMS, CRM, PIM or OMS: those are always heavily bespoke, and writing one takes up to two weeks. Those are always heavily bespoke and can take considerably longer. The difference against a subscription model is not really about the days, though. It is that there is somebody to ask at all: on SaaS a missing feature joins the vendor’s wish list and arrives when they decide, not when you do.

Integrations with external systems

Where Comarch e-Sklep wins

One integration, the one that matters most, is free and it works. That is the heart of the Comarch offer and there is no point relativising it. Product records, groups, prices, customer discounts, stock levels, trading partners with individual price lists, trade documents and credit limits all travel from Comarch ERP into the shop through the manufacturer’s own mechanism, in near real time. You are not commissioning a connector, not negotiating scope, not retesting somebody else’s plugin after every ERP update.

On top of that comes something easy to dismiss when choosing and easy to appreciate during the first outage: one vendor is accountable for both the ERP and the shop. When stock levels drift apart, there is no conversation about whose side the bug is on. There is one phone number, one contract and one entity that has to fix it. In an “ERP from one vendor, shop from another” arrangement that conversation does happen, and it can drag.

The standard integration set in e-Sklep is real too: auction sites (Allegro, eBay, Amazon), payment providers, couriers, price comparison engines. For a distributor selling through several retail channels, that is ready-made infrastructure.

Where Endora wins

A shorter list of things off the shelf, but a different contract.

The important part is that the list is not closed and does not need to be. Endora’s integration layer is generic. There is no list of “supported ERPs”, there is a documented contract: a partner API, signed webhooks and encrypted provider configurations. Any ERP, CRM, WMS or OMS plugs in as an adapter module, whether it is Comarch, SAP, IFS, an in-house system written twenty years ago, or a platform nobody has heard of yet. The adapter registers itself in the platform, gets its own settings and permissions, and the core stays untouched. The Comarch ERP Optima, Subiekt GT, Stripe, PayU and tpay adapters were all built along that same path, and they sit in the Endora integrations catalog.

The specifics this layer stands on:

• A partner API with live OpenAPI: the document is generated from the contracts in the code, so an integrator is never working from an outdated PDF. For e-Sklep I could not find public, open API documentation aimed at third-party integrators. The data exchange point is the ERP, and integrations outside the Comarch catalog are handled through the ERP layer or through third-party tooling.
• An API key pinned to an organization and a channel: the integration sees exactly that company’s prices and limits and can do no more than its own buyer. There is no parameter that bypasses the rules.
• Idempotent orders: a repeated request returns the same order, never a second one. That holds for concurrent repeats too.
• Webhooks signed with HMAC-SHA-256, up to eight attempts with increasing back-off, and a separate view of failed deliveries with manual retry.
• Bulk pricing: one request prices up to 200 line items for a specific organization, guaranteed to agree with the cart to the penny.
• Credentials encrypted with AES-256-GCM, tested on save, masked on read and redacted in the audit log.

KSeF deserves its own paragraph, because both routes work, just differently. In the Comarch arrangement, e-invoicing is solved by the ERP: Comarch ERP Optima has full, automated KSeF 2.0 support on the FA(3) schema, with automatic retrieval of confirmations. After 31 July 2026 it becomes a separate paid package billed against an annual document allowance. If all of your sales pass through Optima, that is a good arrangement and the shop never needs to know KSeF exists.

In Endora, KSeF sits in the platform: invoices and credit notes in FA(3) format sent through a durable queue, the KSeF number on the document, the receipt available for download and a verification QR code on the PDF. The difference shows up precisely when sales come through a channel the ERP does not cover, or covers with a delay: a distributor portal, a marketplace, a mobile app, a POS. With e-invoicing on the ERP side, every such channel has to reach the ERP first for an invoice to exist at all. With e-invoicing in the platform, the channel issues the document itself and the ERP receives it at its own pace. Neither approach is inherently better. One is simply more convenient when the ERP is the only origin of documents, and the other when it is not.

B2B: where Endora Commerce genuinely stands out

Let me start with what there is no point hiding: Comarch e-Sklep in the B2B variant has a solid, well-thought-out wholesale feature set. Selling with no product limit, individual price lists granted to a trading partner in the ERP, net price presentation, hiding prices from anonymous visitors, login-only access to the shop, registration with admin approval, multiple employee logins under one trading partner, minimum order value, selling in fractional units, multi-currency, a customer area with invoices and warehouse documents from the ERP, presentation of the credit limit and the overdue-payments limit with deferred payment blocked once it is exceeded, a made-to-order product configurator, an individual product feed, order header attributes and a mechanism for price enquiries and sales quotes. For a company whose B2B can be described as “regular trading partners buy at prices set in the ERP and pay on terms”, that is the full set.

The difference appears where the selling stops fitting that sentence.

1. A request for quote as a loop, not as an email with a link. In e-Sklep the customer submits an enquiry, the sales rep creates a sales quote with a validity date and a net or gross price, and the customer receives an email notification with a link redirecting to a cart holding the quoted products. That works, but it ends after one round: I found no mechanism in the documentation for a counter-offer, nor for turning an accepted quote into an order without going through the cart. In Endora a request for quote is a full negotiation loop: the customer asks, the sales rep quotes with a lead time and a validity period, both sides can amend the terms, and acceptance turns the quote into an order without re-entering a single line. On top of that there is the none price display mode, which hides every pricing element and routes purchase intent into a request for quote. That is the option for the part of the range that is never sold from a price list.

2. A hierarchy of organizations with inherited terms. In e-Sklep the buyer is a trading partner from the ERP, to which several logins can be attached. That structure is flat: there is no tree for commercial terms to flow down. A company with a head office and fifteen branches is, in that model, either fifteen trading partners or one with fifteen logins. In both cases somebody keeps the consistency by hand. In Endora organizations form a tree: order visibility flows downwards, and the price list and the credit limit are inherited from the nearest ancestor. Changing the terms at head office carries over to the branches that do not have their own.

3. A credit limit as a reservation, not as a number on screen. e-Sklep presents the credit limit granted in the ERP and blocks deferred-payment purchases once it is exceeded. That is sensible control, better than nothing. Endora reserves the limit atomically at the moment the order is placed and releases it when the invoice is paid or the order is cancelled, with payment methods filtered out once the limit runs out. The difference shows exactly where it hurts: two orders placed in parallel by two buyers from the same company.

4. Cart approval on the buyer side. More and more companies have an internal procedure where an order above a certain value has to be approved by a manager. Endora has cart approval switched on per organization, with a full submission path and a decision with a justification. I found no equivalent in e-Sklep: employee login roles control access, but they do not create an order approval process.

5. The sales channel as a first-class dimension. Storefront, marketplace, distributor portal, PWA app and POS are separate channels of the same Endora installation. Products, prices, promotions, content, settings, analytics and the search index all carry separate values per channel. In the Comarch SaaS model, a distributor portal is a separate shop, with a separate subscription, a separate configuration and a separate synchronisation.

6. The realities of wholesale handled head-on. Packaging units (pallets, cartons, shrink packs) with the unit conversion carried into the order and the quote. Quick ordering with cart import from CSV or Excel, search by SKU and attributes, and one-click purchase for customers with a full set of default preferences. Purchase lists, a comparison tool with PDF export, returns and complaints with RMA numbering and credit notes, multi-warehouse stock with reservations and backorders. Plus an audit log recording the state before and after every change, and impersonation that lets a sales rep see the customer’s prices through the customer’s eyes, with a visible banner and a log entry.

Where Comarch e-Sklep has the advantage: the commercial data sits where it belongs and does not have to be replicated. Credit limits, discounts, customer price lists and document history come straight from the ERP, so there are no two sources of truth and nobody asks why the shop shows a different price than Optima. In Endora the price lists and limits live in the platform, and consistency with the ERP is the adapter’s job, something that has to be designed, built and maintained. If your priority is a single source of truth with no layer in between, that is an argument for Comarch.

When Comarch e-Sklep is the better choice

1. You run on Comarch ERP and have no plans to change it. Optima, XL, Altum or XT is your operational centre, your commercial processes are described inside it and your team has known it for years. Native synchronisation is then worth more than any amount of architectural flexibility.

2. You want one vendor accountable for everything. One contract, one support line, one entity that cannot explain the problem away as “the other side’s”. For many boards that is not convenience but a hard condition. And a justified one.

3. Your B2B fits the pattern of “price list from the ERP plus payment terms”. Regular trading partners, assigned discounts, net prices, a credit limit, repeat orders. e-Sklep B2B covers that completely and will be faster and cheaper than rolling out a platform of your own.

4. You do not have and do not want a technical back office. No servers, no updates, no on-call. The Comarch cloud takes the entire operational layer off you for the price of the subscription.

5. You also sell retail through auction sites. Allegro, eBay, Amazon, price comparison engines and couriers are ready in e-Sklep and connected to the same ERP. Endora handles marketplaces with feed templates today, not with two-way API integration.

6. The starting budget is a hard constraint. A few hundred zloty a month plus a partner rollout is a different bracket from a one-off PLN 60-80k. If you are testing whether a B2B channel will pay for itself at all, that is a real argument.

7. You want an interchangeable implementation partner. The Comarch partner network in Poland is wide, and switching implementation firms does not mean rewriting the shop, because the shop belongs to Comarch.

When Endora Commerce is the better choice

1. Selling goes through negotiation, not through a price list. Requests for quote are the main path, both sides exchange terms, and part of the range has no visible price at all. A single round of “enquiry, quote, link to cart” will not carry that.

2. Your customer structure is a tree, not a list. Corporate groups, a head office and branches, commercial terms inherited downwards, order visibility at head-office level. A flat register of trading partners will not model that without manual work.

3. Your order process has steps of its own. Technical review, buyer-side approval, production, picking, partial releases. If your order lifecycle cannot be written down as a closed list of system statuses, the workarounds start costing more than a platform of your own.

4. You are launching several channels at once. Shop, distributor portal, mobile app, POS. In Endora those are channels of one installation, with separate ranges, prices, content and analytics from one admin panel, with no multiplying of shops and subscriptions.

5. You are changing, or considering changing, your ERP. This is the sharpest scenario. e-Sklep is worth exactly as much as the Comarch ERP underneath it. A decision to migrate to SAP, IFS or anything else drags the shop with it, because the shop cannot live without that particular ERP. Endora’s integration layer does not assume a specific product on the other side: changing the ERP means swapping the adapter, not the platform.

6. You have systems nobody supports off the shelf. An in-house WMS, an ageing production system, a CRM with heavily reworked logic, an OMS assembled from several tools. A partner API with live OpenAPI, signed webhooks and keys pinned to an organization and a channel is a different starting point from integrating through the ERP layer.

7. You need changes that are out of reach in a SaaS model. Custom cart logic, an unusual checkout, a specific reservation mechanism, an integration built into the purchase path. In e-Sklep, modifications end at the look of the site. In Endora the code is yours.

8. You want the code and the data. A Git repository on your side, a database on your side, no lock-in and no dependency on whether a given feature survives the next release of somebody else’s product.

9. The Comarch quote starts to include bespoke line items. If the partner’s offer lists a bespoke communication module between the ERP and the B2B platform, or a made-to-order application alongside the subscription, it is worth pricing both routes. At that point you are paying for a subscription and for custom-built software at the same time.

What Endora Commerce does not have

This section is here so the article can support a decision rather than merely leave you convinced.

• A single vendor accountable for both the ERP and the shop. That is Comarch’s strongest card and Endora does not hold it. Your ERP stays where it is and the platform comes from somebody else. When something breaks at the seam, there is a conversation that would not happen with a single manufacturer.
• Upkeep bundled into a single price. Somebody has to maintain the server, the backups and the updates. The Comarch cloud takes that off you entirely. You can run that yourself, or contract it to us or to a partner firm under an SLA.
• An extension marketplace. You will not install a feature in five minutes. Anything unusual is development work.
• A deep market of specialists. Comarch has hundreds of partners in Poland. Endora is developed with a partner or your own TypeScript team, which has to learn the platform.
• A decade of references at extreme scale. Comarch has thousands of live rollouts and years of production peak seasons behind it.
• Full API integrations with marketplaces. Allegro, Amazon and eBay are handled today with feed templates, not two-way integration with the marketplace API. In e-Sklep that is a standard feature.

A short checklist

Answer these for yourself. The answers usually line up on one side.

1. Do you run on Comarch ERP, and do you intend to stay on it for the next five years?
2. Do your customers ask for a price before ordering, or do they buy at prices already assigned to them in the ERP?
3. Do your customers have branches that need to inherit the price list and the limit from head office?
4. Does your order lifecycle fit into statuses like “confirmed, fulfilled, cancelled”?
5. How many sales channels will you realistically need within two years: one or three?
6. Does the partner’s offer list bespoke, separately quoted items alongside the subscription?
7. Is a single vendor accountable for the ERP and the shop a board-level requirement for you, or just a convenience?
8. Is owning the code and the data a requirement for you, or a nice-to-have?

A majority of “we are staying on Comarch”, “selling from a price list”, “one channel”, “no technical back office”, “one vendor is a requirement” points to Comarch e-Sklep. And it points there firmly, not as a consolation. A majority of “we negotiate”, “branches with their own terms”, “unusual process”, “several channels”, “we want the code” points to Endora.

In summary

Comarch e-Sklep and Endora Commerce solve two different problems. e-Sklep answers the need “I have Comarch ERP and I want to sell online”, and it does so quickly, cheaply, in the manufacturer’s cloud and with one entity accountable for the whole thing. You pay for that with a subscription, with a modification ceiling that stops at the look of the site, and with somebody else’s product roadmap deciding what your shop can do. Endora answers the need “I have business-to-business selling with processes of its own and I want the platform to model them”: with requests for quote, a hierarchy of organizations, credit limits and sales channels in the core, no licence fees and the code in your repository. You pay for that with running a server, with the platform’s youth and with the absence of a single vendor accountable for both the ERP and the shop.

The simplest test: if your B2B can be described as “trading partners from the ERP buy at their prices”, e-Sklep will probably be enough and will be cheaper. If the description contains the words “we negotiate”, “branches” or “our orders go through”, it is worth pricing the other option, especially before you pay for a bespoke module bolted onto a subscription.

The Endora admin panel and storefront run online, so the fastest route is to click through the demo yourself. You can also see how a rollout runs step by step, or book a free workshop where we walk through your processes and systems and put a number on the first rollout, integrations included.

And if the conversation points to Comarch e-Sklep being the better fit, we will say so plainly. A failed rollout is not a good reference for anyone.