The question of what technology a system will be built on comes up in almost every conversation about custom software, usually within the first hour. An answer in the form of a list of names, meaning PostgreSQL, Redis, Node.js, Next.js and React, is accurate, yet contributes little to a purchasing decision.
Behind that single question sit six others, considerably more relevant to whoever signs the contract.
Everything below refers to Open Mercato version 0.7.0. That matters when reading this text six months from now: the platform is under active development, so the module list and library versions do change.
What remains when we part ways
The platform core is MIT licensed. That means a full right to modify and develop the code further, with no per-user fees and no permission required from anyone. The foundation is PostgreSQL, Redis and Node with Next.js and React, four technologies you can recruit for in any larger city. There is no proprietary language here, no closed rules engine and no custom data format anyone would have to be extracted from.
There are three practical consequences:
- Ending the engagement comes down to handing over the repository and a database dump, rather than to a migration.
- Data is stored in a standard PostgreSQL database, so your team can read it with its own analytics tools from day one, without asking anyone for an export.
- Another firm can take over maintenance. It does not have to be the team that built the system.
This is a fundamental difference from systems billed per seat, where the end of the contract means losing access to the application and often to the historical data as well.
When will the system be running
The project does not start from an empty repository. The platform ships with more than forty business modules: sales, catalogue, customers, inventory, carriers, payments, complaints and RMA, workflow, permissions, notifications, translations and audit logs. These are not examples to be rewritten, but working modules with APIs, screens and tests.
They come with a full set of integrations: Stripe, webhooks following the Standard Webhooks specification, Akeneo, email, push notifications for iOS, Android and Expo, Discord, IMAP and Gmail. There is also a compliance module for the EUDR regulation, which for a company in a regulated sector is a ready-made item in a tender submission.
The effect on the schedule is measurable: the subject of the project stops being writing a system and becomes fitting one. Custom attributes are added to existing objects from configuration, without code changes, so part of the fitting stops being developer work. The reasons why the remaining part moves faster for us than in the classic model are covered separately in our piece on AI-assisted engineering, and the effect on a single system is shown in the Fortress case study.
Is our data safe
Separation of data between organisations and tenants is enforced at the architecture level, rather than left to a developer to remember on every database query. That distinction decides whether a single mistake in the code can expose one organisation’s data to another.
The rest of the security layer rests on that foundation: tenant data encryption, permissions based on immutable capability identifiers rather than on role names that can be swapped, audit logs with configurable retention, API keys and multi-factor authentication. Building this scope from scratch is usually six to twelve months of work that nobody has to fund or audit a second time.
One mechanism deserves a separate mention, because it sounds like a detail and tends to cause disputes after go-live: optimistic locking is on by default. Two users will not overwrite each other’s changes to the same record without warning.
A caveat: part of the security machinery belongs to a paid package. The subject returns in the section on limits.
Can the system be fitted to our processes
Extensions go through the module system: widget injection, component replacement, API call interception and custom fields. Platform files stay untouched, so each release does not end with a conflict to resolve.
Above that sits a written backward compatibility contract: thirteen categories of public surface that must not be removed in a single release. First a deprecation notice, then a bridge lasting at least one release, and finally migration instructions.
This rules out the scenario where a team maintains its own fork of the code and stays on an old version for years because upgrading has become too expensive. The same mechanism also means you can commission one module from another firm without touching the rest of the system.
What does it cost to run
The starting deployment consists of one server and a database. No Kubernetes, no cluster, no subscriptions to external services. Every heavier layer has a light variant, and switching between them is a configuration change rather than a rewrite of the application.
Below are the thresholds at which further components get added. Each row is one decision deferred in time, and the “start” column requires no additional service and no additional fee.
| Layer | Start | At scale | Switching point |
|---|---|---|---|
| Cache | process memory, SQLite or a file | Redis | more than one application instance |
| Job queues | local on-disk queue | BullMQ on Redis | jobs must survive a restart, or several workers are needed |
| Search | PostgreSQL | Meilisearch | large catalogue, typo tolerance, custom ranking |
| Vector search | pgvector, in the same database | Qdrant or ChromaDB | millions of vectors |
| Files and attachments | server disk | S3 | multiple instances or large volumes |
| Monitoring | application logs | OpenTelemetry, New Relic | production deployment under an SLA |
The above applies to deployment on your own server. One-command deployment starts with Redis and a separate background job process from the outset, so the first two rows do not apply to it.
What it costs per month
The first decision is not about the vendor, but about what you are paying for: saved time or compute.
Path A, deployed in a week. A single command stands up the full set: application, background job process, database, Redis and a public address. No administrator, with a repeatable deployment on every change. The cost of that convenience is roughly twice the bill for your own server.
Path B, optimised for the long run. Your own server with a European provider, everything in containers. The lowest running cost and full control over data location, at the price of a few days of configuration and an ongoing responsibility for updates.
| Scenario | Own server | One command | Major cloud |
|---|---|---|---|
| Pilot, up to 20 people | $14–21 | $30–45 | $60–120 |
| Production, 20–100 people | $60–105 | $85–120 | $400–600 |
| Production plus a separate staging | $105–175 | $150–250 | $700–1000 |
| Multi-tenant SaaS, high availability | $235–465 | $400–800 | $900–2000 |
Amounts are monthly, net and stated in US dollars, at typical load. European servers are billed in euro, so their prices were converted at 1 EUR = 1.1652 USD, the European Central Bank quote of 9 September 2026, and rounded. The ranges themselves are our own estimates from September 2026, based on provider price lists, and are neither quotes nor a measurement from a deployment. Before a budget decision we refresh both the price lists and the rate.
For comparison: an ERP-class system billed per seat, at thirty users and fifty dollars per seat, comes to about 1,500 dollars per month. The difference in favour of your own infrastructure holds up to several hundred users.
The arithmetic also checks out at a smaller scale. Our own invoicing system costs under a dollar a month, and that figure is broken down in the invoice automation case study.
Three items that fall out of the budget
Environments. Staging doubles the bill, a separate development environment triples it. Most cost sheets cover production only. With one-command deployment, a second environment is literally a second set of four services.
Artificial intelligence. Billed by usage rather than at a flat rate. Under heavy assistant use this item can exceed the cost of the entire infrastructure. A locally run model eliminates the API bill, but requires a machine with a graphics card, meaning an outlay of 235 to 930 dollars per month.
The enterprise module licence. Formally it is not infrastructure, yet in a budget it lands in the same line, which is why we present it together with the cost of servers.
Will our data reach an AI vendor
The AI layer is vendor neutral. Anthropic, OpenAI, Google, Mistral, Cohere and Amazon Bedrock are interchangeable in configuration, so switching provider after a change of pricing or policy is a settings change rather than a project.
In a conversation about compliance, something else matters more: Ollama is supported as well, meaning a model running on the client’s own server. Data then never leaves your infrastructure. For a company in a regulated sector this is often a condition of the project going ahead, rather than an advantage.
The platform also supports the MCP protocol, which lets the system connect to the AI tools your team already uses.
The difference between a system with AI inside it and a tool bought on subscription, along with what each means for data ownership, is covered separately in our piece on the four kinds of AI software.
Six limits worth knowing early
Every point below will surface later anyway: at a technical audit, or during contract negotiation.
01. Enterprise modules are paid. SSO login, extended security (MFA, TOTP, WebAuthn keys) and record locking belong to the commercial package from Open Mercato sp. z o.o. and require a licence for production use. The MIT core works without them, yet an organisation with a mature IT function will almost always require SSO. This item should be included in the quote from the start.
02. PostgreSQL is mandatory. There is no support for MySQL, MS SQL Server or Oracle, and no configuration change gets around it. If a corporate database policy applies to you, verify this first, before any conversation about scope.
03. The environment versions are very recent. Next.js 16, React 19, TypeScript 7, MikroORM 7, Node 24. The upside is a long support horizon and no technical debt at the start. The cost is a requirement on hosting: it must offer Node 24, which rules out some cheap shared hosting and older corporate system images.
04. Optional components stop being optional at scale. Redis, Meilisearch and S3 are not needed at the start, yet they become mandatory once the application runs on several instances. Read the thresholds in the table above together with the costs, because the switching point should not come as a surprise.
05. Monitoring requires a receiver of your own. OpenTelemetry and New Relic are wired in on the application side, but the destination those metrics go to is something you choose and pay for separately. It can be Grafana, Datadog or New Relic. The integration itself carries no cost, the receiver’s subscription does.
06. The cost of artificial intelligence is variable. Unlike the rest of the infrastructure, which is billed at a flat rate, the AI layer is billed by usage and under heavy use can exceed the cost of all the servers combined. Two approaches are available: adopting a range for a typical scenario, or running the model locally.
What a demo covers
Five elements that show fastest how the system differs from a spreadsheet and from an older in-house system:
| Element | What it does |
|---|---|
| Collaborative editing | Two people work on the same document at once, seeing each other’s cursor positions. Much like Google Docs, except in your own system and on your own server. |
| Progress on long operations | Importing several thousand records shows a progress bar at the top of the screen and lets work continue, instead of blocking the browser. |
| Edit conflicts | Two people open the same record. The second gets a clear message, instead of silently overwriting the first one’s changes. |
| Live notifications | A change in the system appears for another user without a page refresh. |
| Multiple languages | The interface switches language in full, error messages included. The absence of hardcoded strings is enforced automatically during the build. |
For your IT team: the full list
The rest of the stack determines the quality of the team’s work and the pace of change, yet it does not alter the answer to any of the six questions above. In short: a Turborepo monorepo, dependency injection, schema validation, unit tests, Playwright integration tests and mutation testing, plus custom quality gates in CI.
Turborepo · Yarn workspaces · Awilix · Zod · ts-pattern · Tailwind · Radix UI · TanStack Query · Jest · Playwright · Stryker · ESLint · date-fns · MikroORM
Summary
The code remains your property, the data sits in a standard database, and ending the engagement comes down to handing over the repository and a database dump. The starting deployment needs one server; heavier components are added only when scale demands it, and every threshold can be named in advance. The limits are countable too: the paid enterprise package, the PostgreSQL requirement, very recent environment versions and the variable cost of the AI layer.
The question this text does not settle is who should build and maintain the system. We cover that separately, together with a list of questions to put to any vendor, on our page about choosing an AI software house.
Find out what a system like this would cost you
A free digital audit takes one to two days and ends with a diagnosis of your processes, not a quote. You leave with a scope, a hosting path and a cost range for running it.
Book a free audit →
