Compiling BAS to .exe: Building the Bot, Protecting the Script, Shipping to a Client

While a bot lives in the studio it is your tool. Compiling turns it into a product: a standalone application you can hand to a client, sell, or run on someone else’s machine without showing how it works inside.

What compiling produces

The output is an application that runs without BAS installed and without access to the action tree. The user sees a window with settings - thread count, fields for resources, a proxy list - and a start button. The logic is neither visible nor editable.

One detail matters: the browser engine is not baked wholesale into the file. On first launch the application downloads the environment version it needs, so the client’s first start is slower than usual and requires internet access. If the bot is headed for an isolated network, plan for that up front.

The interface is part of the job

The classic first-build mistake is assuming compilation is the whole task. Your action tree becomes a program operated by a person who knows nothing about BAS. Anything you hardcoded into variables is beyond their reach.

So before compiling, decide what the client is supposed to change and surface it as settings: logins, URLs, limits, delays, file paths. Leave everything else inside. A good test: if changing a value would require rebuilding the bot, that value belongs in the interface.

Script protection: what it buys you

A compiled build does not reveal the logic, which shuts down the main leak path - a client opening your project and handing it to another contractor. For most commercial work that is enough.

Still, be clear-eyed about it. Protection stops a user or a competitor, not a prepared reverse engineer. The practical conclusion is short: never store anything in the script that you cannot afford to give away. Keys to your APIs, passwords to your infrastructure, private tokens - in a bot on someone else’s machine, all of it ends up in someone else’s hands eventually. If the bot needs access to your service, issue it a separate, narrowly scoped key you can revoke.

Before you hand it over

Walk this checklist - it saves weeks of support:

• Relative paths only. An absolute path from your machine does not exist on theirs.
• Resources included. Anything the bot reads must travel with it or be created on first run.
• Errors are actionable. A client will not read a stack trace - the message should say what to do: “proxy not responding”, “the input list is empty”.
• Logging is on. When something breaks on their side, the log is all you will get. Write to a file, not only to the screen.
• Limits tested on another machine. Their CPU and memory differ; a thread count that is comfortable on your PC may not survive on theirs.

Why the compiled bot behaves differently

Divergence between studio and build almost always traces to three causes.

Paths and files. In the studio the project sits in a known folder; after building the layout changes, and anything read by absolute path breaks.

Speed. In the studio you watch the bot and unconsciously give it time. In a build running more threads, pages load slower and the waits that “were enough” stop being enough. Waiting for an event always beats a fixed pause - on someone else’s machine that stops being a style preference.

Environment. Different OS, different version, different antivirus. An automation app that downloads components on first run is a textbook false-positive candidate; warn the client before the first phone call, not after.

Versions and updates

A compiled bot is a snapshot of the logic at build time. The moment a site changes its markup, the selectors break for everyone you already shipped to.

So agree on updates up front, not after the breakage: how you deliver a new version, who pays for adapting to site changes, and how long support lasts. A bot handed over “forever” for a fixed fee becomes an open-ended obligation on the exact day the site ships a new frontend.