Custom ERP development makes sense when the processes that make you money (production, orders, field teams) do not fit any off-the-shelf ERP without costly compromises. For most other companies, an existing ERP or a hybrid approach — keep the accounting software, build custom operations modules only — is the cheaper and safer choice.
We at WebForge build custom enterprise software for companies in Romania, and "should we build our own ERP?" is a frequent question in large projects. So this article is not a pitch: we show you the criteria for deciding, what a realistic custom ERP looks like for an SME, which integrations are mandatory in Romania, how delivery works in phases and how the total cost compares over 3–5 years. Including the cases where we recommend not building anything.
Custom ERP or off-the-shelf ERP: how to decide
The short answer: an off-the-shelf ERP wins when your processes resemble those of other companies in your industry, and a custom one wins when a specific process is your competitive edge or when adapting an existing product would cost almost as much as building. You decide on processes, not on a preference for "something of our own".
The off-the-shelf market splits into a few categories, each with its own logic:
- Modular open-source ERPs (for example Odoo). The Community edition is open-source (LGPL), while Enterprise is proprietary. They cover many areas (sales, inventory, manufacturing, accounting) and can be extended with your own modules. Licensing and implementation cost depend on the edition and number of users; heavy customisation, however, inherits the platform's constraints.
- ERPs for mid-size companies (for example SAP Business One). Established products with an ecosystem of implementation partners and rich functionality. They suit companies that need standardisation and classic processes; costs include licences, partners and consulting.
- Romanian accounting and management software. Built around local legislation (accounting, VAT, e-Factura, SAF-T) and strong on finance and classic stock management. For very specific operational flows, flexibility is usually more limited.
- Niche applications (invoicing, inventory, service, HoReCa). They solve one area, very well and cheaply, but do not connect the rest of the company on their own.
| Criterion | Off-the-shelf ERP | Custom ERP | Hybrid |
|---|---|---|---|
| Start | Fast, predefined processes | Slower: analysis, build, testing | Fast on accounting, phased on operations |
| Fit with your processes | Good on standard processes, compromises on specific ones | Exact, the way you work | Standard where standard, custom where it matters |
| Upfront cost | Lower (licences and implementation) | Higher (build) | Medium, spread out |
| Recurring cost | Per-user or per-module licences, upgrades | Maintenance and evolution, no per-user licences | Small accounting licence + maintenance |
| Code ownership | No; vendor dependency | Yes, if it is in the contract | Only for the custom modules |
| Main risk | Process compromises, expensive customisations | Project too big, growing scope | Integration between the two parts |
For the broader picture of software development for companies, our guide to custom software development covers stages, choosing a team and general risks.
When a custom ERP makes sense (and when it does not)
Building is worth it when you have a specific process no existing product fits, when you already pay a lot for customisations or licences, or when work happens outside the office. It is not worth it when your processes are standard, the team is small or the processes are not yet clear.
Signs a custom ERP is worth discussing
- Your process differs from everyone else's. Make-to-order production with variants, your own recipes or technologies, pricing by specific rules, site work or field interventions. There, a generic ERP forces you to change the process or to keep working in parallel in Excel.
- You already juggle 3–5 tools that do not talk to each other. Excel for stock, an invoicing program, a CRM, WhatsApp groups for teams. Data is copied by hand, errors creep in and nobody has the full picture.
- Customising an off-the-shelf product would cost as much as building. When the list of adaptations grows long, you end up paying for custom development anyway, but on a platform you do not own.
- You need an app for people in the field. Service, installation or delivery teams reporting from their phones, with photos, signatures and consumed stock.
When NOT to build a custom ERP
- Your processes are standard. Classic retail, services with simple invoicing, an ordinary warehouse: an existing product covers them and you are live in weeks.
- Your processes are not written down or nobody owns them. Software does not fix chaos, it freezes it in code. First clarify how you work, then digitise.
- You want to replace your accounting. Accounting, VAT, SAF-T and statutory reporting change constantly. It is rarely worth rebuilding them when maintained programs exist for exactly that.
The hybrid option: keep the accounting, build the operations
The hybrid approach means keeping the accounting and invoicing program you already use (SmartBill, Oblio or a classic management program) and building custom only the operations modules that give you an edge. It is often the best investment-to-result ratio.
The logic is simple: accounting is a regulated, constantly changing domain where existing products are mature and cheap. Operations — how you receive orders, how you produce, how you plan teams, how you track stock — is where your company is different. You build the latter and connect it to the former through an API.
A typical hybrid system looks like this:
- the custom application manages orders, stock, production or field jobs;
- when an order or job is completed, the application automatically issues the invoice in the invoicing program through its API;
- the invoicing program sends the invoice to the national e-Factura system and the status comes back into your application;
- aggregated data lands in a report or dashboard for management.
We cover the integration mechanics with invoicing programs in the SmartBill API integration guide, and the same reasoning applied to customer relationships in custom CRM vs off-the-shelf CRM — the logic is identical, only the domain differs.
Do you have a process you could not find in any ERP? Tell us how you work and we will honestly tell you whether custom, hybrid or an existing product makes sense.
Typical modules in a custom ERP for SMEs
A realistic custom ERP for an SME does not have 30 modules but 3–5, chosen by where you lose time or money today. Here are the most common ones and what each solves.
| Module | What it does | Who it suits |
|---|---|---|
| Inventory and warehouse | Receipts, issues, transfers between locations, stocktaking, minimum-stock alerts, barcodes | Distribution, retail, manufacturing |
| Orders and sales | Quotes, orders, statuses, pricing by your own rules, link to invoicing | Almost any B2B company |
| Production | Recipes / bills of materials, production orders, raw material consumption, traceability, cost per order | Manufacturers, workshops, apparel, furniture |
| Field teams | Job scheduling, mobile app with photos and signatures, materials used, intervention reports | Service, installers, maintenance, deliveries |
| Reports and dashboards | Sales, margin, stock, productivity, in real time, by role | Management and department heads |
What we generally do not recommend building custom: general ledger accounting, payroll and tax reporting. You connect to them, you do not reimplement them.
Mandatory integrations in Romania: e-Factura, invoicing, banks
The e-Factura obligation belongs to the company issuing the invoice and can be met through the invoicing program, so an ERP must connect, directly or indirectly, to the ANAF system (SPV), to the invoicing and accounting program and, usually, to the banks. Integrations can eat a lot of time in a custom project, so you plan them in the first phase, not at the end.
- e-Factura / ANAF SPV. Invoices are submitted in a standardised XML format (UBL) and receive a validation response. Two approaches are practical: your application issues the invoice through the invoicing program, which handles submission, or your application connects directly to ANAF services. The first is simpler and cheaper; the second is justified at high volumes or special requirements. Details in our guide to e-Factura automation.
- Invoicing and accounting programs (SmartBill, Oblio and others). Many offer an API for issuing invoices, product lists and statuses. We always check in the provider's documentation exactly what the API allows, because limits differ.
- Banks and payments. Importing statements (for example in standard formats banks provide) to automatically reconcile receipts with invoices. Availability and format depend on your bank, so it is confirmed during analysis.
Every integration means analysis, testing with real data and long-term upkeep, because APIs and formats change from time to time. That is why the number of integrations is one of the biggest cost drivers.
Phased delivery: from one process to a full system
The safest way to build a custom ERP is in phases: start with one process that hurts, put it into production, then add modules based on what you learned.
- Discovery. We map the real processes, existing data, users and required integrations. The result is a module list prioritised by impact and a proposed architecture.
- Phase 1: one process, one module. For example orders and stock, or field job planning, with basic invoicing integration. A pilot project / module typically falls in the 10,000–30,000 EUR range, and a project like this reaches its first usable version in 3–8 months. What matters: at the end of this phase, people actually work in the system.
- Pilot and adjustments. You run in parallel with the old method for a short period, fix issues, then switch the old method off. Leave time for surprises here.
- Next phases. Production, purchasing, reports, the mobile app. Each module is delivered and used before the next begins, and priorities can change along the way.
- Maintenance and evolution. The system lives as long as the company: fixes, security updates, new requirements.
Who owns the source code and why it matters
In a serious project, the source code and the data are yours, with full access to the repository, documentation and delivery pipeline at handover. This is the structural difference from an off-the-shelf ERP, where you stay dependent on a vendor, its licensing policy and its roadmap.
To make that true in practice, check the contract for:
- transfer of copyright / usage rights over the code developed for you;
- delivery of the code, technical documentation and access (repository, hosting, domains, databases);
- accounts and access (repository, hosting, domains) in your company's name, not in the name of the team that built the system.
A custom ERP does not free you from dependencies, it changes their nature: you depend on a team that understands the code, not on a licence. With good documentation, you change the team without changing the system.
Total cost over 3–5 years: how to compare properly
Compare total cost of ownership over 3–5 years, not just the starting price: an off-the-shelf ERP is cheaper at the start but adds licences and customisations every year, while a custom one costs more upfront and less recurrently. There is no universal winner, only calculations made with your numbers.
On our side, the only anchors we publish are those on the custom enterprise software page: a pilot project / module typically falls between 10,000 and 30,000 EUR, and a full system with multiple modules, integrations, migration and roles starts from 30,000 EUR. The real quote comes after Discovery. For off-the-shelf ERPs, ask for written quotes.
To compare fairly, put the same lines in the table for both options:
| Cost line | Off-the-shelf ERP | Custom ERP |
|---|---|---|
| Licences | Recurring, often per user or module | No product licence; possibly third-party services (hosting, APIs) |
| Customisations | Paid separately, on the vendor's platform | Paid as development work, with no licence fee |
| Maintenance | Included in the licence or separate support | Maintenance contract |
What pushes the price up
- Number of modules. Each module has its own screens, rules and reports.
- Number and complexity of integrations. e-Factura, invoicing, banks, online store, couriers: each is a separate mini-project.
- Users and roles. Permissions per department, approvals, audit logs, mobile app.
- Data migration. Volume and quality of the old data.
If part of the investment can be funded, check the guide to European funds for digitalisation for open programs and how an application is prepared, without relying on promises.
Risks and how to reduce them
The risks of a custom ERP are well known: growing scope, users who do not adopt the system, dependence on a single team and fragile integrations. All of them are reduced by the same strategy: a small start, involved users and a clear contract.
- Scope creep. The feature list grows along the way. Fix: short phases, prioritisation by impact and an explicit "not now" list.
- Weak adoption. The system is good, but people keep using Excel. Fix: involve end users in Discovery and the pilot, name an internal owner and switch off the old method on a fixed date.
- Dependence on the building team. Fix: full code handover, documentation, accounts in your company's name, readable and tested code.
- Integrations that change. Formats and APIs evolve. Fix: contracted maintenance, error monitoring and tests on critical integrations.
The best risk reduction stays the same: start with one process. If the first module brings no value, you lost one phase, not a whole project. If it does, the next module is justified by real numbers.
Frequently asked questions
How long does custom ERP development take?
The first usable version is usually delivered in 3–8 months, and a full system is built in phases, depending on modules, integrations and migration. The exact duration is set after Discovery, and between phases you already use what has been delivered.
How much does a custom ERP cost?
A pilot project / module typically falls between 10,000 and 30,000 EUR, and a full system with multiple modules, integrations and migration starts from 30,000 EUR. Price depends on the number of modules, integrations, users and roles and on data migration; a firm quote comes after Discovery.
Can I keep my accounting program?
Yes, and it is often the recommended route. The custom application connects to the invoicing and accounting program through its API (where available), issues invoices and receives statuses, while your accountants keep working in the program they know.
Who owns the source code?
You do, if the contract says so: you receive the repository, documentation and access at handover.
If you are facing the "off-the-shelf or custom ERP" decision, write to us on the contact page. After an initial conversation we will tell you whether it makes sense to build something — and, just as honestly, whether it does not.