Imagine: you’ve been using an ERP system for three years. All processes configured, employees trained, deal and document history — it’s all there. Then one morning you get an email: “The service is shutting down in 30 days.” What do you do?

This isn’t a theoretical question. SaaS business services shut down regularly — from small startups to large international products. For some users, it means 2-3 months of chaos and retraining. For others — a complete halt of operations. In this article, we’ll break down how “open source code” in ERP protects your business from this scenario — and how our model differs from classic open-source.

What “open-source ERP” usually means

When you hear “ERP with open source code” — usually it refers to large public projects: Odoo Community, ERPNext, Dolibarr. They share a common model:

• Public repository on GitHub or GitLab — anyone can download the code
• License (GPL, AGPL, MIT) — formally allows use, modification, distribution
• Community — thousands of developers worldwide
• Self-installation — you deploy the system on your server, configure it, maintain it

Sounds ideal — but there are nuances. Classic open-source ERP requires a strong IT team for implementation and support. For a business of 10-50 people, it’s often unaffordable: you need a DevOps engineer, a database administrator, developers for your industry. Or you hire an integrator — and again depend on a single contractor.

That’s why many small and mid-sized businesses choose SaaS — fast, no in-house IT team, support out of the box. But SaaS brings you back to the same vendor lock-in: your data and processes are with the vendor, and if something happens — you’re back to where you started.

How code access works in ERPJS

ERPJS offers two ways to work, and each addresses independence in its own way:

Option 1: SaaS on erpjs.biz. You sign up, get your company in our cloud, and start working within 15 minutes. The business logic code is on our servers — you don’t have direct access to it. This is a fast start, but you don’t have full control over the system — you depend on us as a SaaS vendor.

Option 2: On-premise installation on your server. We deploy ERPJS on your server — physical or cloud. And this is where the key point begins: the business logic code — documents, procedures, registers, reports, forms, validations — automatically ends up on your disk. Not “access on request,” not “we’ll send you an archive when you ask” — but simply files on the server that you have direct access to.

The business logic is fully readable JavaScript. Not minimized, not obfuscated. Any JS developer can open the files, read the logic, understand what’s happening. The system core (framework) is delivered as a built library — as is standard in the Node.js ecosystem. This is not a limitation: all industry-specific logic and processes can be adapted without touching the core.

This isn’t “open-source ERP” in the classic sense — we don’t have a public GitHub with thousands of contributors. But it is — technical accessibility of the business logic in your hands, which in practice gives you the same level of control over your processes.

What this gives you in practice

Let’s move from theory to specifics. Here are 4 consequences of having the business logic code on your server:

1. Any JS developer can work with the business logic. No need for a “certified ERPJS consultant.” The business logic .js files on your server are regular JavaScript. Hire a freelance developer, in-house, an outsourcing company — any option works.

2. You don’t depend on our roadmap. Need a specific feature for your industry, and it’s scheduled in our plan for next year? You can commission its implementation from any developer working with the code. You don’t wait for us.

3. You have a Plan B for any events with ERPJS. Service closed, we got acquired, war — doesn’t matter. Your system keeps running on your server. Support is provided by the developer you have now — or a new one you find.

4. Data + code = full control. This is the fundamental difference from pure SaaS, where you only have data, but without code you can’t change anything. And from pure open-source without a vendor, where you have the code, but all responsibility is on you.

By the same logic, we wrote about when Excel stops working — there too, the main risk is the absence of control. And if you’re just choosing an ERP — our guide 7 criteria for choosing will help you consider independence as one of the points.

SaaS or on-premise: which option is right for you?

These aren’t two stages of one path, as is often written. They are two different products for different segments — and you need to choose at the start.

SaaS is right for you if:

• You’re self-employed, a freelancer, or have 1-3 people on the team
• One location: coffee shop, salon, small store, service
• Simple product catalog, simple processes
• Control over code is not relevant to you — you need a fast start, not a long-term strategy

At this level, vendor lock-in is a theoretical risk: your processes are standard, the volume of data is limited, switching to another system if needed won’t be a catastrophe. Sign up, start in 15 minutes, work.

On-premise is the right starting choice if:

• You have manufacturing, distribution, a chain of stores, an auto service, a warehouse
• 10+ employees and multiple legal entities
• Complex processes, specific industry, possibly — integrations with other systems
• Regulatory requirements (pharma, medical, finance) or corporate security policy
• You understand that dependence on a single SaaS vendor is a business risk

Here on-premise is not “the next level when you mature,” but the right choice from the start. The earlier you’re on your own server, the less to redo as you grow. And the less risk if something changes with us.

Transition from SaaS to on-premise remains technically possible — for example, if you started as a small team on SaaS, and then the business grew. Data is transferred from SaaS to on-premise and back — it’s the same product, the same database. But it’s better not to wait until “we should have gone on-premise from the start.”

Who else can work on your ERP besides us?

This is where the story gets interesting for IT companies and developers. If a client has on-premise — the code is with them, meaning any external IT company can potentially maintain and extend it. This creates space for collaboration. Three formats we see as realistic:

Format 1: Referral. You bring a client to ERPJS, we handle them. Your role — sales and initial consultation.

Format 2: Implementation and customization. You as an IT contractor: implement ERPJS for the client, configure it for their processes, write specific modules. You get money from the client directly for your work. The business logic code is in your hands through the on-premise installation.

Format 3: Self-hosted SaaS. You take the code, deploy your SaaS under your own brand — for example, a specialized ERP for pharmacies, auto services, or beauty salons based on ERPJS. This is a white-label option.

Specific terms of cooperation for each format — individually, case-by-case. If you’re interested in discussing — write to us, we’ll figure out how it might look in your situation.

FAQ