Most Polish SMEs run on dozens of small tools that quietly decide whether an invoice goes out today. Excel macros, Access databases, PowerShell scripts, SQL procedures added years ago by a former in-house IT. Nobody really remembers what they do. As long as they work — nobody asks.
We call this shadow development: software built and kept running outside the official IT function, with no documentation, no version control, often without the owner's knowledge. It's not the same as shadow IT (unofficial SaaS purchases). Shadow development is quieter and more dangerous, because it usually sits in the heart of a process — in invoicing, in settlements, in the export to the accounting office. And it usually has one author who remembers why a particular IF clause looks exactly that way.
You will really notice it on the Friday afternoon when that author has already left and your sales team pings you: "Why do commissions look weird today?"
What it looks like in a typical SME
One of our clients — a 28-person plastic packaging manufacturer running on enova365 and a handful of Google Sheets — asked us to audit this kind of tooling. The result: 34 scripts and macros, of which only 9 had an active author inside the company. The rest came from a former in-house IT guy, two accountants who had left, and an intern from four years ago.
The biggest risk sat inside a single Excel file: the macro that calculated sales commissions. Its author had left 18 months earlier. In the meantime, the sales director had been signing off on monthly commission statements — without knowing that since a contract addendum from 2024, one bonus was being calculated differently from what the addendum said. The company had been overpaying commissions to the tune of PLN 47,000 before anyone noticed. And it wasn't sales that noticed — the accounting office did, at year-end close.
Second on the list: a PowerShell script that ran every night, copying files from a network share to a key customer's FTP server. Nobody remembered which customer, which server, or what would break if the script failed. It had, in fact, failed a year earlier — and nobody noticed, because the customer never reported the missing files.
Third: an Access database the production planning team used to schedule five production lines. It worked, until someone had to add a new material. Then it turned out the "material code" field was 10 characters in one table and 12 in another — and that the weird step where the planner "opens query Q7 and clicks the down arrow three times" was also part of the process.
None of this is pathological. It's the normal state of a company that grew for ten or fifteen years faster than its IT did.
Why it happens
Shadow development arises for the same reason shadow IT does: the official tools don't deliver what people need to do. The difference is a lower barrier to entry. Anyone who can write an Excel formula or record a macro can "help themselves". And because it works — nobody protests.
Three typical sources:
- The ERP can't do what someone needs by yesterday. A sales rep gets a sales report out of the ERP but no commission calculation. They sit down, build a macro that does what the ERP won't, and the problem is solved for today. But the macro sticks around and becomes part of the process.
- The former in-house IT loved PowerShell. Every problem got a script. Every script ran out of Task Scheduler on some server. Nobody ever got a list of them. After they left, the company doesn't even know what will happen tonight.
- One person built "their own system". Usually an Access database or a Google Sheet with Apps Script. It works — and at some point three other people start using it. By then it's a production system of the company, just without a contract and without a backup.
How to run the inventory
You don't need PLN 20,000 of tooling for this. You need one person who will spend two or three weeks on it, and a simple sheet with four columns: name, what it does, who knows it, what breaks if it stops.
Step 1 — list the places where code lives. Don't hunt for code, hunt for places. The usual suspects in a Polish SME:
- directories like
\\server\data\macros,\\server\it\scripts,C:\Scriptson the server, - Task Scheduler on every server (including the ERP application servers),
.xlsm,.accdb,.mdbfiles on departmental shares (sales, accounting, planning),- cron / systemd timers on Linux, if any,
- Apps Script in Google Workspace, Power Automate and Power Query in Microsoft 365,
- stored procedures and jobs in the ERP's SQL Server database (Comarch Optima, enova365, Subiekt — all of them let you add procedures),
- "Outlook macros" on long-tenured employees' workstations.
Step 2 — for each item on that list, ask three people: who wrote it, who understands it today, what happens if it stops working. If the answer to any of these is "no idea" — flag the item red.
Step 3 — for every red item, answer one question: does the process this tool supports touch revenue, tax obligations, or security? If yes, it goes to the top of the fix-it list.
That's it. Two weeks, one spreadsheet, no magic. The first version doesn't have to be complete — it has to be honest.
What to do with what you find
There's no single right answer. There are four, depending on the value and the risk:
- Document and leave it. If the script is simple, has run for years, and at least one person understands it — write one paragraph about it and drop a copy in a repository (even a plain OneDrive folder with version history). Not everything has to be rewritten.
- Rewrite into a controlled form. If the tool touches money (commissions, invoices, price lists, supplier settlements) or security (access, backups, exports to the accountant) — move it to something with version control, tests and a single clear owner. Usually that means a plain script in a Git repo, or rewriting the macro as a stored procedure inside the ERP.
- Replace it with a function of the official system. Sometimes the commission macro exists only because nobody ever turned on the commission module in the ERP. Instead of rewriting, ask the ERP vendor whether this isn't already standard.
- Turn it off. A good chunk of the scripts do nothing useful anymore — they generate a report nobody reads, copy a file nobody needs. Switch them off for a week. If nobody asks — switch them off for good.
For every tool that stays, assign a second human. Not documentation — a human. Documentation goes stale, a second human asks questions.
What next
Shadow development won't go away, because your business will keep changing faster than its official IT. The point is to know what you have — and to make sure the critical things have an owner, a second human, and a place where they live officially.
If you don't know where to start in your business — start with an hour of conversation. We do this kind of audit regularly, and something unexpected usually turns up. Better that it turns up during the audit than on a Friday afternoon when the commissions look weird.
As long as it works, nobody asks. On the day it breaks, the one who usually asks is the customer.