Comparison
Internal application or ERP module for the process left behind
You already run an ERP, yet one important process stayed on paper or in spreadsheets. Two very different roads start here.
The pattern repeats in nearly every company that has finished an ERP rollout: ninety per cent of the operation moved into the system, and the remaining ten per cent — scheduling installation crews, tracking complaints, approving a non-standard quote, logging laboratory samples — carries on living in a shared spreadsheet. The first option is to ask your ERP vendor for their module covering that process. It sits in the same database, uses the same master data and the same user accounts, and the information stops travelling between applications. The price is another per-seat licence, a configuration fee and, most of the time, accepting the way the vendor decided the process ought to work. The second option is a separate application built precisely around your flow and wired to the ERP through an API that pulls across customers, products and documents. It costs more at the start, fits exactly, and changes at your pace. The criterion that decides is simple: how standard the process really is, and how much of your competitive edge lives inside it.
Let’s talk about your project
Message us on WhatsApp or send an email — you talk directly to a developer.
office@northdan.com · +40 752 070 247
Key takeaways
What the vendor's module gives you
One database, one login, reports that automatically include the new flow, and one phone number to call when something stops working. You build nothing and you carry no maintenance — which matters a great deal if nobody technical sits inside the company.
What the separate application gives you
The process stays exactly as you want it, including the steps that set you apart from competitors. The interface can be designed around whoever uses it every day — warehouse staff, field crews, production supervisors — instead of a generic enterprise screen.
The difference in speed
A module goes live in weeks if it covers the need; if it does not, the customisation joins the vendor's roadmap queue and is measured in quarters. Your own application starts more slowly, and afterwards changes in days.
The risk each option brings
The module deepens single-vendor dependence and raises the monthly per-seat cost. The separate application adds a second system to maintain and an integration that must survive every ERP upgrade — where contract clauses matter more than code does.
The four-step test before you ask for a quote
Step one: describe the process in ten lines and ask your ERP vendor whether their module covers it with no customisation. If the answer requires more than three modifications, you already have the signal that this is not a standard process. Step two: count the people who use it daily and multiply by the monthly licence over five years; that is the number you are comparing against. Step three: ask what happens to those customisations at the next major version — who retests them, and at whose expense. Step four: check whether the ERP exposes a documented API, because the second option depends entirely on it.
If the answer at step four is that integration happens only through manually exported files or direct access to the database, treat that as a major risk finding. An application glued to somebody else's database breaks at the first upgrade, and the repairs end up costing more than the module you did not want to buy.
When building anything is the wrong answer
If the process is infrequent, involves three people and produces twenty records a month, do not automate it. A well-run shared spreadsheet, with clear rules for filling it in and one person accountable, is cheaper and more flexible than any software, and the project time would drain into meetings that produce nothing. We say this even when we are the ones who would build it.
The investment becomes justified once the concrete signals appear: the same data keyed twice into two places, errors that reach the customer, departments waiting on each other for an approval, an inability to answer a simple question about the status of a job. At that point you count the hours lost each month, compare them with the cost of each option, and the decision makes itself.
Frequently asked questions
Can the ERP vendor refuse to integrate with an outside application?
Commercially they can discourage it, or charge for access to the programming interface. Which is why the terms of access to your own data are negotiated when the ERP contract is signed, not three years later, when the whole operation already sits there and you have no leverage left.
How do I stop the separate app becoming another island of data?
By deciding at the outset which system owns each type of information. Customers, products and fiscal documents stay in the ERP and are read from there; your application owns only the data belonging to its own process. When both systems write the same field, differences appear that nobody can ever reconcile.
How long does an integration with an existing ERP take?
If the system has a documented interface and a test environment, indicatively two to four weeks for the core flows. If documentation is missing or access is hard to obtain, the timeline doubles, and most of it is spent waiting for answers rather than writing code.
What if the module covers only half the process?
Check whether the covered half is the hard one or the easy one. If the module solves the complicated part and the rest fits in a simple form, buy it. If it only covers record-keeping while the rules that matter stay outside, you are paying licences for an expensive register.
Similar pages
Related resources
Let’s talk about your project
Message us on WhatsApp or send an email — you talk directly to a developer.
office@northdan.com · +40 752 070 247