Buying an ERP will not make a Montenegrin company EU-ready on its own. Buy software for the work every company does the same way. Build it for the process that is your advantage, because no product on the shelf was designed around that one.
The position
For a company in Montenegro getting ready for the EU market, the first software on the shopping list is usually an ERP. Buy one, but know what it does. An ERP runs the back office: the part of the business that looks the same in every company. Law and accounting practice set the rules for that work, and the vendor keeps the product in line with them for all its clients at once.
Your own process is a different matter. Think of pricing construction work to the last cubic metre, or staffing seven hotels for one season. The way you do that work is why clients pick you, or why you get it done faster and cheaper than the competition. Squeeze it into a product built for everyone and the difference goes with it. Leave it in Excel next to the ERP and the most important work in the company stays the least documented. That process is where custom software is the right call.
What's actually happening
Most of the Montenegrin companies we talk to work the same way. Accounting runs in software that already handles fiscalisation. The core of the business runs in spreadsheets, email and the heads of a few people.
Sokla Architects prepares bills of quantities for construction companies and investors. A bill of quantities lists every material and every piece of work in a build, with its description and unit, and it decides whether the project is cost-efficient. For years, Sokla built every bill by hand in Excel and then checked it row by row. There was no central database, so finding an earlier item meant digging through folders.
Casa del Mare runs seven small hotels on the Montenegrin coast, with around 30 permanent and over 100 seasonal staff. Every peak season brings thousands of applicants. HR ran all of it in Excel: candidates, employees, contracts and salaries. Search was slow, records were entered by hand and the spreadsheet could not keep up with the seasonal spikes.
Neither process fitted a product off the shelf, so both companies had software built around it. An ERP would have kept their books in order and left the bills of quantities and the seasonal hiring where they were.
The EU makes that gap more expensive, because much of being EU-ready comes down to answering questions about how your work is done. Who can see an applicant's CV? Who changed a quantity in a budget, and when? Where is personal data stored, and for how long? A spreadsheet passed around by email cannot answer them. An ERP answers them for the books, and the books were rarely the problem.
Some of this is already a legal requirement. If you sell to people in the EU, GDPR applies to you today, whether or not Montenegro has joined. An EU company that shares its customers' personal data with you will want a data processing agreement signed first.
Why the obvious answer doesn't work
The obvious answer is to buy a bigger system and have it customised until it fits. That trade gets worse with time. Every customisation is code the vendor does not maintain. Each upgrade has to be tested against it, some upgrades break it and the implementation partner bills for every change. The process still has to fit the product's data model, so the work that made you different gets more standard with every compromise.
There is a deeper cost. The ERP vendor sells the same product, with the same process built in, to your competitors. That is exactly what you want for payroll. For the work clients choose you for, running it the way everyone else does takes away the reason to choose you.
The opposite mistake is building everything. A company that writes its own invoicing takes on every change to VAT and fiscalisation rules, alone and for good. When Montenegro moved to electronic fiscalisation, the vendors of invoicing software did that work once for all their clients. A custom invoicing module would have done it for one company, at that company's expense.
The useful question is which of your processes are standard and which one is yours. The software follows from the answer.
ERP, CRM or custom software
An ERP runs accounting, invoicing, stock, purchasing and payroll. Its rules are the same for you as for your competitors. Buy one, configure it and resist customising it.
A CRM runs the sales pipeline: leads, deals, follow-ups and the history with each client. Selling works in a similar way across most companies, so this is a product too. We build software for a living and still run our own sales in Pipedrive and our projects in ClickUp.
Custom software runs the process that is yours: the bill of quantities, the peak-season hiring, whatever your clients would miss if you worked like everyone else. It costs more up front than a licence and it needs an owner on your side. In return it fits your process exactly, and the roadmap is yours.
Many growing companies end up with all three. Connect them so each record lives in one place: the ERP holds the money, the CRM holds the clients and the custom tool holds the work that makes you different.
What we do instead
When a company asks us to build or replace software, we work through five moves, and the first two happen before anyone writes code.
- Write the process down. One page per process: the steps, who does each one, what goes in, what comes out and where it is stored today. If nobody can write that page, software will only automate the confusion. We wrote more about this step in Before you implement AI, understand the process.
- Mark every step standard or yours. A step is standard when law or common practice sets how it is done: bookkeeping, VAT, fiscalisation, payroll, a sales pipeline. A step is yours when clients choose you because of how you do it. It is also yours when no standard product expects the way your business does it, like hiring for seven hotels in one season. Buy software for the standard steps and keep it standard: configure the product, never rewrite it.
- Build the part that is yours, small and around your own data. One database, one workflow, one output. For Sokla that was a catalogue of more than 200 work positions with their descriptions and units, a drag-and-drop report builder and a PDF an investor can read. Sokla now saves around three hours on every report, and more than 400 projects have gone through the platform since launch. For Casa del Mare it was an application form that feeds the HR database and a candidate database that turns an applicant into an employee in one click. HR filters the staff by hotel, sector and role. Hiring and HR processes now run 70% faster, with more than 5,000 applicants handled in a peak season.
- Design in what EU partners will ask about. Roles that decide who sees which records. A log of who changed what and when. A clear answer to where personal data lives, how long it stays and how it is exported or deleted. These are cheap to design in at the start and expensive to add to a system that is already running.
- Make sure you can take it elsewhere. Custom software is an advantage only while you can change it, and that includes changing who works on it. Owning the code helps only if another team can pick it up. We made the full case in You should be able to fire your vendor.
Casa del Mare's platform was supported by Montenegro's Ministry of Economic Development through its grant scheme for digitalisation. Programmes change, so check what is open before you budget a build of your own.
When this doesn't apply
If your process is the same as your competitors', buy. A custom build would recreate a product that already exists, at a higher price and with you as its only customer.
If an industry product already fits your process with small changes, buy that too and spend the money on something only you can do.
If the volume is low, a well-kept spreadsheet is fine. Sokla's platform works because hundreds of projects go through it. A company that prepares a handful of reports a year should keep the spreadsheet and look again when the volume grows.
And if nobody on your side can own the tool, wait. Custom software needs one person who decides what it does next. Without that person it drifts away from the process it was built for.
Where to go next
- Related service: Custom Software Development
- Case studies that prove it: Sokla's bill of quantities platform and Casa del Mare's HR platform
- Or talk to us: tell us about your project
Was this useful?
