A small business owner realises that Excel is no longer enough. The paper profit does not match reality, the warehouse lives its own life, every report takes an hour of manual work. It is time to choose an ERP system. He opens Google, reads 5-7 comparisons — and gets lost. Some articles are vendor advertisements. Others are academic checklists with 30 criteria, where “intuitive UI” sits next to “microservices architecture”.

This post is an attempt to give a different format. Not 30 criteria, but 10 specific questions the owner should ask themselves and the vendor before signing a contract. If the answer to at least 3 of them is “I don’t know” or the vendor avoids a direct answer — that is a signal to stop and look at more options.

The questions are split into three blocks: first to yourself (about your own business), then to the vendor (about the product), and finally — about the economics. The sequence matters: without understanding your own processes, every demo looks equally beautiful.

Where to start — choosing a vendor or analysing your business?

Start with the analysis of your own business. Without understanding your own processes, every demo looks equally beautiful. Before looking at vendors, answer questions 1-3 below for yourself. Otherwise the demo will charm you with design, and later it will turn out that a key module is missing or “will be in the next version”.

Block 1. Questions to ask yourself

1. Which processes do we automate first?

Short answer: One process or several? Doing everything at once is the classic mistake that sinks ERP projects.

A small business usually has 2-4 key processes: warehouse, sales, finance, production, service, rental. Choosing which of them to automate first determines not only the ERP modules but also the budget and timeline.

Risk signal: “we automate everything at once in 1 month”. That does not happen in practice. The adequate approach is phase 1 (one or two critical processes, basic accounting), phase 2 and onwards — gradual expansion.

2. How many users today and in 2 years?

Short answer: 3, 10, 30 or 100? Different systems are optimised for different sizes, and the price “explodes” differently as you grow.

The number of users determines not only the licensing model (per user, per module, flat) but also the architectural requirements. Most vendors have non-linear pricing — extra modules and paid options kick in at certain thresholds. Some (ERPJS included) keep a directly proportional per-user price without tariff changes.

Ask the vendor: “Show me the price calculation for my current headcount and for +20 users in 2 years”. If the difference is more than 4x for a 4x growth — that is a non-linear model, take it into account.

Risk signal: the vendor does not ask about planned growth. This means the price may “explode” later, when you are already locked in.

3. Which 3-5 reports does the owner want to see daily?

Short answer: Name 3-5 reports you want to see daily. If you cannot — that is the first task before choosing an ERP.

Concrete examples of owner reports: margin by product group, working capital, top-10 debtors, cash flow for the week, sales by manager. Every business has its own set.

Important nuance: do not ask the vendor “do you have such a report?” — even if they do, yours will be different (different cuts, different filters). Ask differently: request a demo of how data is entered for your key report — you will see whether the interface has the dimensions, analytics, and objects you need. If data is entered in the right structure, building the report is a matter of technique (1-3 days of work). If not, the report will not appear even if the vendor promises: there will be gaps and inaccuracies.

Risk signal: the vendor brags about “200+ ready reports”. Mostly these are standard accounting reports that a small business owner does not need. Ask about your specific report.

Block 2. Questions to ask the vendor

4. Does the system cover my critical processes without customisation?

Short answer: If yes — standard path. If no — how flexibly can it be modified? How much will modification cost?

No ERP system covers 100% of a specific business’s needs out of the box. The question is what percentage it covers and how the rest is built up. In the ERP world there are two extremes: “monolithic” systems with closed code (modifications only through the vendor, often expensive) and flexible platforms with open architecture.

Risk signal: “yes, we will modify anything you want” without an estimate of hours and cost. Ask in writing: “here is our scenario X, how many hours and how much will it cost?”

5. SaaS or on-premise — which model is critical for you?

Short answer: SaaS — quick to start, minimum IT costs, but data is with the vendor. On-premise — full control and security, but you need your own server.

Some vendors offer only one of the two — this is a limitation. If the vendor offers only SaaS, you are forever dependent on their server, prices, and existence. If only on-premise, you have no easy way to “try with minimal cost”.

The most flexible option is when both are available, and the client can start with SaaS and move to on-premise when it becomes critical, or vice versa. Or start with on-premise from the beginning if the business is serious and data is critical. Details — in the post Open Source Code in ERPJS: SaaS or On-Premise With Control.

Risk signal: the vendor says “SaaS is the only right way, on-premise is the last century” OR vice versa “on-premise means security, SaaS is not good”. Both models have their place.

6. Is the business logic code open? What happens if the vendor shuts down?

Short answer: On-premise installation alone does not guarantee that you can work without the vendor — most systems use online licence keys with limited validity. Ask separately: what happens to data access if the key stops being renewed.

This question seems theoretical until it becomes real. SaaS services for business shut down regularly. What happens next depends on the combination of three factors: SaaS or on-premise, open or closed code, and how licensing works:

• SaaS, closed code: complete stop. Data can theoretically be taken as a DB backup, but without a UI it is useless. The result — months of chaos and retraining.
• On-premise with online key, closed code: when the key stops renewing, the system may not start at all. Without updates or support — even if you manage to start it, any problem stays unresolved.
• On-premise with open business logic and an offline licence fallback: data access is preserved even without the vendor (e.g. basic read-only mode or a limited single-user mode). That is enough not to lose your data and to have time to calmly prepare a migration to another system. This is not “full freedom”, but a real plan B in case of vendor problems.

Risk signal: the vendor says “we have closed code and no on-premise” — full dependence. Or there is on-premise, but “the key is online, nothing starts without renewal” — in practice still dependence, just hidden. Ask specifically: “what happens to my data access if we stop the cooperation tomorrow?”

7. Which integrations are already ready, and how much will those built for you cost?

Short answer: There is no vendor who has ALL integrations ready. The important question is which 1-2 integrations are critical for your business: are they already there, or do they need to be built from scratch.

Critically important for most small businesses:

• Bank-client — for any business with banking operations
• Postal/delivery providers (Nova Poshta, Ukrposhta) — for trade with shipping (more about Nova Poshta integration)
• Fiscal cash register (e.g. Checkbox) — for retail
• Marketplaces (Rozetka, Prom) — for online trade

If your key service is already integrated, that is 1-2 weeks saved on implementation. If not, count it: developer hours × rate + testing time.

Risk signal: the vendor says “we integrate with anything” without a list of what is ready. Ask specifically: “what integration do you already have working? Can you show an example from a real client?” The honest reality: no vendor covers the whole market. The sensible strategy is several genuinely working integrations plus willingness to build your case.

Block 3. Project economics questions

8. How much does the first year really cost?

Short answer: Not “the licence”, but “licence + implementation + customisation + training”. Often implementation equals 1-2 annual licences.

Three cost items often hidden at the first consultation:

1. Implementation — system setup for your processes, data migration. Can range from a few thousand to tens of thousands depending on scope.
2. Customisation — module modifications, specific reports, non-standard logic. Usually billed hourly.
3. User training — real time that has to be allocated. Without training the system sits idle.

How is the price calculated: per user, per module, or flat? This also affects the total cost as you grow.

Risk signal: “price only after consultation” with no upper bound. An adequate vendor can name at least a range (“from X to Y for a configuration of a similar business”).

9. How long from contract to the moment I actually start working in the system?

Short answer: Do not confuse “implementation duration” with “time to start working”. An adequate vendor breaks the project into phases: basic accounting starts in 2-4 weeks, full functionality is built up over the next 3-12 months.

The integrator’s pure time for the standard scope of a small business is indeed around 2-4 weeks. In reality the project stretches over months, but not because of the vendor — because of organisational issues on the client side: data preparation for migration, user testing, decision-making inside the team.

It is better to start using the system in limited functionality and grow, than to spend 6 months setting up an “ideal” system before the first login. Early use is also a chance to understand what is really needed (often what seems important at the start turns out differently in real work).

The risk signal is not “2 weeks”, but:

• The vendor promises to launch the entire functionality in a month — this will be a hack job.
• The vendor does not break the project into phases — the process will get stuck (“a bit more polishing, a bit more”).

An adequate vendor will say: “Basic accounting — 2-4 weeks to start. Then module X — a month, module Y — two, in total roughly 4-6 months to full scope depending on your pace.”

10. What does exit from the system look like if I decide to migrate?

Short answer: Can I take my data? In what format? Can I keep using it if I stop paying the vendor?

This is a question few vendors like to answer directly — and that is itself a signal. In SaaS with closed code, exit is largely a myth. A DB backup in your hands without a UI is useless; manual export of registers to Excel one by one takes weeks and does not give a full picture.

In on-premise with open code and an offline licence fallback, the system is physically yours and basic data access remains even without the vendor. Not necessarily “everything as before with all users at once”, but enough so that you do not lose your data and have time to calmly prepare a migration to another system.

Risk signal: evasive answer to a direct exit question.

What to do if you spot 3+ red flags?

Do not sign the contract “while the discount lasts”. Time pressure is a standard trick owners fall for under emotion: “well, the discount is here, let’s hurry”. The reality — the system will be with you for at least 3-5 years, a week or two for extra questions changes nothing.

Concrete steps:

1. Ask for written answers to disputed questions — not “in chat with a consultant”, but in the commercial proposal.
2. Look at at least 2-3 other systems for comparison. The goal is not to pick the cheapest, but to understand the market and calibrate prices and timelines.
3. Ask for references and contact existing clients yourself — by phone, not through an organised meeting under the vendor’s supervision. Ask specifically: what hurts after a year of use, what had to be reworked, did the initial promises about timelines and budget hold up.

How do these 10 questions look in ERPJS?

Briefly, block by block — so you can compare with other vendors:

• Business processes: document flow (sales, purchases, warehouse, production, rental, service), financial and management accounting, project management. CRM exists, but it is not our main strength.
• SaaS and on-premise — both options from the start, no contract re-signing. You can begin with SaaS and switch to on-premise, or start with on-premise right away.
• Reports. Standard set (trial balance, cash flow, sales) is included. Real approach — first capture the data correctly, then build the reports your business actually needs. Usually 1-3 days of work per report.
• Integrations. Ready: Nova Poshta (waybill in 20 seconds), bank-client (statement import out of the box; outbound payments — done in custom projects), Checkbox (fiscal register), Rozetka and Prom marketplaces. EDI and a few others — not yet, built per client case with transparent hour estimates.
• Business logic code is open in on-premise — you can hire a third-party JS developer. Details: Open Source Code in ERPJS.
• Data access if the cooperation ends. Even without an active licence key the client retains basic access: one user with full read+write mode, others — read-only. This is not “business as usual”, but a guarantee that you will not lose your data even if something happens to us.
• Timeline: basic accounting starts in 2-4 weeks, full functionality — 3-12 months depending on scope. We work in phases.
• Pricing: SaaS — on the pricing page, no “hidden until consultation”. On-premise — after a short consultation on configuration.

Frequently Asked Questions