In modern software development, the gap between an on-premises development environment and a production environment often hides dangerous assumptions. One of the most common is to assume that copying files is equivalent to installing a program. However, copying files is just transferring bits; Installing involves resolving dependencies, compiling native modules, and configuring the runtime. When a marketplace deploys a plugin by simply copying its directory, it skips the entire installation process. The result is a system that works on the developer's machine—where the dependencies already were—but fails on the end-user's machine. This problem, known colloquially as 'it works on my machine', has deep roots in dependency management, especially when using native modules that require compilation.
Let's imagine a plugin that offers two modalities: one that connects to a remote API using only pure JavaScript, with no native dependencies, and another that needs a local SQLite database, which requires compiled C++ modules such as better-sqlite3 and fs-ext. In the development environment, the npm install command has already been executed, leaving node_modules ready. But when copying the plugin through the marketplace, native dependencies don't exist. When the server tries to load the module with require, it fails with MODULE_NOT_FOUND. The plugin dies on boot, without having done anything. This scenario is not uncommon: it affects any application that combines pure code with compiled dependencies and is distributed via file copy.
The solution is not to ask the user to run npm install manually. In a marketplace-driven install flow, that action breaks the experience and reduces adoption. Instead, the plugin itself should self-provision its dependencies at first boot time, and only when they are needed. To achieve this, a small launcher (bootstrap) is used that runs before the main server. This launcher is written exclusively with native Node.js modules (fs, path, child_process), without relying on anything in node_modules. Its role is to decide whether native dependencies are needed or not. If the application is running in remote mode (without SQLite), the launcher starts the clustered server directly, at no additional cost. If local mode is needed, check to see if dependencies are already present. If not, run npm ci (not npm install) to install exactly the locked versions on the package-lock.json, ensuring reproducibility. After installation, check again, and if it fails, abort with a clear message.
One of the most subtle challenges is competition. When a user opens multiple instances of the plugin (e.g., multiple Claude windows or multiple agents), processes can start simultaneously and attempt to install in the same directory. Two concurrent npm ci can corrupt the dependency tree. To avoid this, an atomic lock based on mkdir is used: an attempt is made to create a temporary directory (.native-install.lock). If the operation fails with EEXIST, it means that another process already has the block. The algorithm then waits, checks if the dependencies are ready (another process has ended), if the lock is obsolete (more than 5 minutes, indicating a process that failed), or if a maximum timeout of 2 minutes is reached. This design avoids racing conditions and ensures that only one process performs the installation, while the others wait or continue if it is already done.
The general lesson is profound: any system that distributes software via file copying (marketplaces, installers without a package manager, serverless deployments) should consider dependency provisioning as part of the runtime, not the build. Continuous integration (CI) tools often install dependencies before running tests, hiding the problem. To detect it, a smoke test is necessary to simulate a clean installation: copy the files to an empty directory, without node_modules, and run the launcher exactly as a user would. If the test passes, the code is robust. If it fails, it is detected before the version is released.
This approach has direct applications in the development of custom applications and custom software. At Q2BSTUDIO, we understand that each project has unique infrastructure and dependency needs. For example, when building AI solutions for enterprises, we often combine large language models (LLMs) with vector databases that require native modules. If we deploy these systems in cloud environments (AWS, Azure) using containers or serverless functions, on-demand provisioning is crucial to avoid excessive boot times and silent failures. Our teams apply similar self-install and blocking patterns to ensure that both AI agents and data pipelines work reliably out of the box.
Cybersecurity also benefits from this design. A plugin that assumes pre-installed dependencies can be vulnerable to path spoofing attacks or malicious dependencies if the user does not control the installation process. By centralizing provisioning in a minimalist launcher, the attack surface is reduced. In addition, using npm ci with verified package-lock.json prevents unauthorized version injection. In our AI developments for enterprises, we combine these practices with vulnerability analysis in dependencies, offering secure and auditable solutions.
Another relevant aspect is the integration with business intelligence services such as Power BI. When we build custom connectors or extensions for Power BI, we often need to install native drivers or compression libraries. By applying the same philosophy—checking dependencies only when they are used and provisioning them on demand—we prevent the end user from having to run additional scripts. This aligns with our business intelligence services offering, where we prioritize user experience without sacrificing reproducibility.
From a business perspective, this pattern allows teams to scale frictionlessly. When a new developer joins a project, they don't need to run manual installation commands; The system itself is configured at startup. This is especially valuable in environments that use AWS and Azure cloud services, where virtual machines or containers are constantly being created and destroyed. A launcher that auto-provisions native dependencies ensures that each instance is identical, eliminating the classic 'on my machine works'.
In short, copying files is not installing. For a plugin or application to work predictably in any environment—on-premises, cloud, or marketplace—the runtime itself needs to manage its dependencies identifyingly, concurrently, and with clear error messages. At Q2BSTUDIO we apply these principles in every custom application project, ensuring that our artificial intelligence, cybersecurity and cloud services solutions offer maximum reliability from the first start. Because in the real world, it's not enough for code to be well-written; It must also be able to get going on its own.
