LupusScripts began as a unique, simple and fast automated checkout Chrome extension, but it turned into my biggest software project. It peaked at 1000 users, 5000 followers on Twitter, and well over 10,000 successful checkouts of limited products. Through this journey, I've honed my software development skills, understood the essence of real-user interactions, managed frontline support and experienced the daily hustle of startup operations.
Born from the insights of my brother and a good friend, both into reselling, LupusScripts was engineered with adaptability in mind. During hyped releases, websites might tweak elements to stump bots. While most bots would grind to a halt, LupusScripts shoulders 90% of the task, allowing the user to step in and rectify the minor roadblock. This fusion of automation and human intuition makes LupusScripts a failsafe choice during high-pressure releases
Together with my brother and friend, we struck a deal: I'd develop an MVP, and they'd find the first users. And so, we went live with the initial version, focusing solely on the modules of Solebox, Snipes, Onygo, Zalando, and Supreme.
As users interacted with our MVP, their feedback was invaluable. Responding to this, we incorporated several of the most requested modules. However, the marketplace was becoming crowded, prompting a desire to differentiate LupusScripts. My approach involved creating a tool that could control multiple browsers via NestJS websockets. Although this attempt didn't entirely hit its mark, it paved the way for the much-celebrated auto-updater feature. To support this feature, I integrated a backend function on Firebase, enabling version tracking.
The journey through Chrome Extension development was a learning curve, presenting unique challenges:
Background Contexts: Chrome's manifold contexts initially posed integration issues. My remedy was to create a unified API tailored for storage and messaging according to context. Upon discovering @extend-chrome, it appeared to be the solution. However, balancing both led to a lot of technical debt.
Transition to Manifest_version 3: The shift to MV3 brought about the removal of persistent background pages, necessitating a substantial rework of our codebase. The challenge was compounded when it became evident that Parcel 2 didn't offer support for MV3. This led me on a journey through various bundlers, including Rollup and Vite, as I sought an optimal solution. This experience not only emphasized the nuances of tool selection in development but also paved the way for the subsequent discussion on Turbo Repo and the monorepo approach.
Monorepo Missteps: Aiming to consolidate the development process, I ventured into establishing a monorepo setup using Turbo Repo. This strategy was to converge the ecosystem within a singular repository. Despite investing considerable time, it became apparent that complications arose, especially regarding bundlers mishandling imports/types from various modules. This endeavor contributed to our technical debt and emphasized the wisdom of adhering to established systems and avoiding the pitfalls of over-optimization. It highlighted the significance of stringent version control and establishing clear quality benchmarks.
