What are the pros and cons of Open Mercato? An developer's view

Open Mercato pros and cons at a glance

If you would like to learn about Open Mercato and its applications first, read our article ‘Open Mercato: What it is and why we implement it for our clients’.

Open Mercato advantages from a developer’s perspective

The Open Mercato features and benefits we value most in our work include ready-made application functionality and the ability to develop custom features. The benefits depend on how well this functionality meets the company’s needs and how much additional code is required. Clear application development conventions also help us work with AI assistants, a topic we will cover in a separate article.

A faster start with a ready-made application foundation

Building a system from scratch requires features such as login, permissions and a way to separate data from different organizations. Open Mercato provides this functionality, allowing work on the rules of a specific process to begin sooner. At Tandemite, we used this foundation to build a product data enrichment solution. Open Mercato provided login, organization management, task queuing and email notifications. Our modules handled product documentation processing and work with AI.

The creators promote Open Mercato with the phrase ‘Start with 80% done’, highlighting the availability of ready-made application functionality. How much development work it saves depends on the company’s requirements. To assess this benefit, it is worth building a prototype of one complete process, from a user entering data to the result being passed to another system. This trial shows which features can be used straight away and which need adapting or extending.

Custom extensions that are easier to maintain during updates

Custom features can be developed without changing Open Mercato’s core code. This makes them easier to maintain when the framework is updated. The documentation describes the rules for extending applications and maintaining compatibility between versions, helping the team plan updates.

The benefit may become apparent after a year or so, once the system has its own forms and business rules. Following the intended extension conventions makes it easier to identify which elements need checking after a version change. It also reduces the risk of having to merge changes manually across multiple core files during an update.

An update requires checking what has changed in the new version and how it affects the application’s custom features. The instructions in the repository help establish whether code changes or data migration will be needed. This work, along with extension testing, must be included in the maintenance budget.

No per-user license fees for the open-source core

The MIT license covering Open Mercato’s open-source core allows it to be used without license fees for additional accounts. This matters when planning access for a large organization or a network of partners.

Suppose a company wants to give 200 people access to the system. Some will log in only to approve an order. Under a subscription charged per user, these people may still need a paid account, depending on the provider’s terms. Open Mercato’s open-source core does not require fees for additional users. A larger user base may, however, increase the load on the infrastructure and the amount of support and administration work. Costs may rise, for example, if a more powerful server is needed.

The absence of fees for additional accounts is one way Open Mercato can reduce operational costs. Another is automation. If the system reduces manual order entry, employees will spend less time processing orders. License savings and time savings should be calculated separately, then compared with the cost of building and maintaining the solution.

Access control and separation of organizations’ data

Open Mercato offers RBAC, or role-based access control, with support for individual user permissions. It also provides multi-tenancy: different organizations can use a shared application while keeping their data separate. Features are available for logging operations and encrypting selected fields with keys assigned to each organization.

In a business partner portal, this makes it possible to restrict each partner’s view to their own orders while giving head office staff access to orders from all partners.

Access control is one part of system security. An implementation must also address custom extensions, backups and administrator permissions. If the operation history needs protection against changes, its storage method and access to the database must be reviewed.

Open Mercato disadvantages and limitations

Open Mercato’s limitations affect the project schedule and the scope of responsibilities once the system goes live. For each limitation, it is worth identifying when it may increase project costs and how to account for it in the work plan.

A young framework with frequent changes

Open Mercato has a shorter development history than mature business platforms. New releases and upgrade instructions are published in the repository, including changes that require adjustments to applications.

The risk increases when a company plans extensive custom extensions but expects minimal developer involvement after implementation. For example, a change in how permissions are interpreted may require views and integrations to be checked again, even if the code still runs.

To reduce problems during updates, it is worth testing the most important processes, checking new versions in a separate environment and establishing an update schedule. A maintenance agreement should specify who assesses an update’s impact on the application and the timeframe for applying security patches. The UPGRADE_NOTES.md and BACKWARD_COMPATIBILITY.md documents help with this by describing changes between Open Mercato versions and the rules for maintaining compatibility with custom extensions.

An ongoing need for implementation work

Implementing Open Mercato requires process configuration, data migration and integration with other systems. The company also needs a team responsible for application development and managing the environment.

Some changes in Open Mercato require a developer. For example, adding a custom document approval rule may involve estimating the work, changing the code and updating the application. During system design, it is therefore worth establishing what administrators will be able to change themselves through settings and what will require support from the implementation team. AI assistants can help speed up application development if the team knows how to use them and check the quality of generated code.

Infrastructure and maintenance in the total cost of ownership

Open Mercato’s total cost of ownership (TCO) includes implementation and the expenditure incurred throughout the system’s lifetime. The calculation must account for hosting, database administration, backups, monitoring and updates, as well as feature development and user support.

Processes that use AI also incur charges for external models. When building the product data enrichment solution, we selected models for the individual stages of the process. In a project like this, processing costs also depend on the choice of models and the volume of material submitted for analysis.

Companies that need additional features can use the commercial Open Mercato Enterprise package. It includes multi-factor authentication, single sign-on (SSO) and user directory synchronization, among other features. If the company needs these capabilities, the package cost should be included in the implementation estimate.

When comparing proposals, it is worth using a common period, such as three years, and the same service scope. A proposal that includes a rapid response to failures and regular data recovery tests will have different costs from one that only provides a server.

For a small team with a standard process, an off-the-shelf SaaS solution, meaning software provided on a subscription basis, may cost less. The deciding factor will be the combined cost of fees, required integrations and work on the client’s side.

Integration availability needs to be checked

The Open Mercato ecosystem is still developing. The project provides a separate repository of official modules. The availability of a specific integration with an ERP system, accounting software or a commerce platform must be confirmed for each implementation.

The product data enrichment solution we developed illustrates how integration scope is defined. Descriptions and SEO metadata were transferred from the Open Mercato application to Pimcore after the user had reviewed them and made any necessary corrections. The onward transfer of data from Pimcore to Magento shops was handled on the client’s side. When estimating a project like this, the scope of the PIM integration and the publication of data to shops must therefore be defined separately.

The greatest cost may arise when an integration has to handle exceptions, such as partial order fulfillment, a price correction after approval or resending data after a failure. A working product import covers only part of this scope.

Before preparing an estimate, the team should describe the directions of data transfer, the frequency of synchronization and how errors will be handled. If a ready-made module exists, it is worth checking its compatibility with the system version, its test coverage and who is responsible for updates. This provides a basis for estimating the work that will remain after installation.

Technology choices and architectural rules

Open Mercato uses TypeScript, Next.js, PostgreSQL and Redis. The project’s packages are available through npm, the package registry for the JavaScript ecosystem. The team developing and maintaining the application should understand these technologies and the rules for building custom modules.

If the company uses other technologies, implementation may require staff training or support from a partner. A process for releasing new versions and responding to failures must also be established. For a small process, this preparation can account for a significant share of project costs. For a team familiar with these technologies, Open Mercato’s shared structure makes it easier to add features and review code. When choosing the framework, it is therefore worth considering who will develop and maintain the application in the years ahead.

Additional work for a B2C online shop

Open Mercato can be used to build a backend for sales and operational processes, including an order management system (OMS), connected to a separate customer-facing application. This architecture requires planning the part of the shop that buyers interact with.

If the project centers on online retail, the entire purchasing journey needs to be assessed. Product search and presentation, the shopping cart, payments and returns all matter. Work on shop performance and usability will also be required.

In a project like this, Open Mercato can handle a specific process, such as approving non-standard orders. The scope of the e-commerce platform and the way the two applications will connect should be defined before work begins.

Open Mercato pros and cons compared with off-the-shelf SaaS and building from scratch

The comparison below puts Open Mercato advantages and disadvantages in the context of three approaches to delivering a project. A specific estimate requires a common scope of features and level of maintenance.

Off-the-shelf SaaS has an advantage when the standard product matches the company’s processes and configuration covers most needs. It is then worth checking the cost of required add-ons, data access terms and integration limitations.

Building from scratch may be justified when the technical requirements or the way the system operates are so specific that a ready-made framework would require costly adaptations. This decision requires a budget for the application’s basic functionality and its subsequent maintenance.

Open Mercato can be a good option when its existing functionality fits the project and the company needs its own business rules. Open-source code reduces some forms of dependence on a single provider, known as vendor lock-in. Continuity of development still requires documentation and the ability to hand the project over to another team.

SAP S/4HANA, Salesforce, Odoo and Sylius address different needs: extensive ERP processes, customer relationship management, modular business management and e-commerce, respectively. Comparisons with Open Mercato should therefore focus on the specific scope of the project. In some implementations, the framework can handle an additional process or portal connected to one of these systems.

When SAP S/4HANA is the better choice

SAP S/4HANA is an ERP system, combining the management of enterprise resources and processes. For a project covering finance, manufacturing and procurement, its existing functionality may favor choosing SAP. Open Mercato can then be considered for a separate process or a portal working with the ERP system. This is an architectural assessment that depends on requirements and available integrations.

When Salesforce is the better choice

Salesforce offers CRM, or customer relationship management software, as a service. Sales Cloud includes features such as managing sales opportunities and forecasting results, and its pricing includes per-user fees. If this scope meets the sales team’s needs, Salesforce may make it easier to launch a solution. Considering Open Mercato as a Salesforce alternative requires calculating the cost of implementing the required functionality and maintaining it.

When Odoo is the better choice

Odoo is a modular ERP system available in an open-source Community edition and a commercially licensed Enterprise edition. Their feature sets differ. Odoo may be the better choice when a company wants to manage sales, purchasing, inventory and accounting in one system, and the available applications meet its needs. Before making a decision, the required edition, localization and cost of modifications must be checked.

When Sylius is the better choice

Sylius is an e-commerce framework available as an open-source solution and in a commercial Plus version. When the main focus of the project is the shop and its purchasing process, Sylius’s specialization makes it worth including in the assessment. Open Mercato can complement such a solution with custom operational processes if they justify maintaining an additional application.

Open Mercato strengths and weaknesses in projects with large product catalogs

A large catalog requires an assessment of the number of variants, languages and sales channels. Data relationships and update frequency are equally important. Two catalogs with similar product counts can involve very different implementation scopes.

Custom data processing rules can account for a significant part of a project like this. When working with electrotechnical products, we developed modules to interpret product data sheets, classify products using the ETIM standard, which organizes them into classes and features, and extract those features from documentation. Open Mercato provided the functionality needed to run the application, while we developed the logic for industry-specific data ourselves. Assessing the framework’s suitability should therefore cover both the ready-made elements and the amount of code needed to handle the particular catalog.

Dividing responsibilities between PIM and Open Mercato

In the solution we developed to enrich electrotechnical product data, Pimcore remained the product information management (PIM) system, while Open Mercato handled the enrichment process. Prices and price lists were held in the client’s separate ERP system. This combination requires a clear division of responsibilities: during PIM implementations, the team needs to establish where each type of data originates and which system is responsible for keeping it up to date.

If the project requires extensive data completeness checks, translation management or specialized publication rules, it is worth assessing the PIM system’s existing capabilities and the cost of filling any gaps. Each requirement should be assigned to the system responsible for meeting it.

Integration and performance at greater scale

The weaknesses of the chosen solution often become apparent when handling exceptions. What should happen if some products fail validation? How should an interrupted import be resumed? When will the user see a change made in the PIM system? The answers translate into specific development tasks.

Performance needs to be tested using data with a structure close to the real dataset. The trial should cover concurrent user activity and bulk catalog updates. The results will help estimate server resources, synchronization time and the optimization work required.

When do Open Mercato’s benefits outweigh its drawbacks?

To decide when to use Open Mercato, assess the following conditions against a specific process. Each answer should be supported by requirements, a budget or a prototype.

Conditions that favor choosing Open Mercato

• The company has a non-standard B2B process whose rules change frequently.
• The framework’s ready-made elements cover a substantial share of requirements, as confirmed by a prototype.
• Many people need access, and current license costs account for a significant share of expenditure.
• The company needs control over application development and how data is stored.
• A team or partner is in place to take responsibility for updates, integrations and maintenance.

Conditions that favor another solution

• The process fits within the standard functionality of an available SaaS product, and the cost of using it is acceptable.
• The budget covers only the system launch.
• Specific, mature integrations are required, and their availability in Open Mercato has not been confirmed.
• The project is mainly concerned with a B2C online shop and a standard purchasing journey.
• The organization needs a product with a long track record of maintenance.

The answers carry different weight. The lack of a maintenance team may determine the decision even when the licensing model is favorable. Open Mercato benefits for business should be assessed in terms of shorter processing times, fewer manual corrections or lower costs of access to the system. A prototype helps establish the scope of work required, while an implementation and maintenance cost calculation helps assess the project’s financial viability.

If you are considering Open Mercato, talk to Tandemite about your project. A useful starting point is the process you want to improve, the systems you use and the planned scale of operations. This provides a basis for comparing the implementation scope and ongoing maintenance costs.