Shipping a Python AI Bot: The Pre-Launch Cleanup We Almost Skipped

We were staring at 94 files, nearly 30,000 lines of code—a fully-functional AI Agents Salebot that was ready for the world, except for one glaring problem: nobody had asked what actually belonged in version control.

The project had grown organically over weeks of development. It had solid bones—17 core Python modules, working tests, proper async/await patterns throughout. But when you’re about to publish on GitLab, “almost ready” means you’re still not done. We needed to answer three critical questions: What stays? What gets locked away? And how do we protect what we’ve built?

The licensing decision came first. The codebase inherited MIT licensing, which felt too permissive for a sophisticated bot handling API interactions and security logic. We switched to GPL-3.0—copyleft protection that ensures anyone building on this work has to open-source their improvements. It’s a two-minute change in a LICENSE file, but it reflects years of philosophy.

Then came the real reckoning: our .gitignore was incomplete. We were accidentally tracking docs/archive/—internal development notes that had no business in a public repository. The data/ directory held databases and logs living in local environments. Worse, Vosk speech recognition models were sitting in the repo, each weighing megabytes. None of that belonged in Git.

We pruned aggressively. Out went the heavy model files, the local databases, the archived dev notes. We kept .env.example as a template so newcomers could bootstrap their own environment. What remained was clean: source code in src/, tests in tests/, utility scripts in scripts/, documentation separate and maintainable.

The initialization mattered. We used git init --initial-branch=main --object-format=sha1, explicitly specifying SHA-1 for compatibility with GitLab and historical consistency. The first commit was meaty but purposeful—94 files from bot.py entry point through the complete module tree. Commit hash 4ef013c wasn’t a dump; it was a foundation.

We configured the remote pointing to our GitLab instance, ready to push. That’s when DNS resolution failed and the GitLab server proved temporarily unreachable. But honestly, that’s fine. The local repository was pristine and ready. One command awaits: git push --set-upstream origin main.

What I learned: Publication isn’t deployment. It’s a deliberate decision to respect whoever clones your code next. Clean history, clear licensing, documented ownership, excluded artifacts. When that push goes through, it won’t be chaos arriving at someone else’s machine. It’ll be a codebase they can actually use.

Your mama’s so FAT she can’t even push files bigger than 4GB to a repository. 😄