I started building my own cryptocurrency trading bot because I wanted full control over how trading strategies were created, tested, and executed.
What started as a personal project eventually grew into a trading automation platform with backtesting, scripting, plugins, a visual strategy editor, and support for multiple exchanges.
This post isn’t about trading strategies or profitability. It’s about building the software, the problems I ran into, and something I seriously underestimated: finding customers.
Building the Platform
The initial idea was simple. I wanted people to be able to write trading strategies in JavaScript, backtest them using historical data, and run them without having to build all the infrastructure themselves.
I also wanted people without programming experience to be able to create strategies, which led me to build a visual strategy editor.
The platform was built around Node.js and JavaScript, with a plugin system to extend its functionality.
As the project grew, I ran into plenty of technical problems. Some were expected, while others took much longer to solve than they should have.
Sandboxing User Code
This was easily one of the most time-consuming parts of the project.
The platform allows users to write JavaScript strategies and plugins. The problem is that you’re essentially running user-provided code in an application that handles exchange API credentials and potentially real money.
I needed a way to let strategies execute JavaScript without giving them unrestricted access to the host environment.
That meant dealing with execution isolation, controlled APIs, permissions, and how user code interacts with the rest of the application.
Simply removing require() or hiding a few globals isn’t enough to make JavaScript execution secure. There are plenty of ways to accidentally expose functionality you never intended to expose.
I spent a lot of time researching different approaches, testing edge cases, and rethinking parts of the implementation.
Even now, I wouldn’t describe sandboxing arbitrary code as a problem you solve once and forget about. It’s something you have to keep in mind whenever the system changes.
Packaging a Node.js App Was More Painful Than Expected
One thing I really underestimated was how much trouble I’d have turning my Node.js application into a standalone executable.
I had quite a few issues with native modules, bindings, and dependencies that worked perfectly during development but suddenly became a problem when packaged.
Node.js SEA wasn’t quite ready for my use case, so I went with @yao-pkg/pkg. It got the job done, but not without a fair amount of workarounds.
I wish Bun or Deno had been viable options when I started. Unfortunately, by the time their tooling became a realistic option, I’d already dealt with most of the packaging issues, and switching runtimes would’ve meant dealing with a whole new set of compatibility problems.
This is probably one of my biggest complaints about Node.js. I like working with it, but having to rely on third-party tools and workarounds just to ship an executable is something I could’ve happily done without.
Writing Code Was Easier Than Finding Customers
This was the part I underestimated the most.
I was comfortable spending hours debugging, redesigning parts of the architecture, or implementing complicated features. That’s what I enjoy doing.
But once I had a product that I wanted other people to use, I had to figure out how to actually reach them.
I tried to understand pricing, marketing channels, positioning, and how to present the platform to potential customers.
The crypto space made this particularly frustrating. There are countless trading bots advertised with unrealistic promises, and I didn’t want my product to be associated with that.
I wasn’t selling a magic money-making machine. I was building a tool that lets people create, test, and automate their own strategies.
Explaining that difference wasn’t always easy.
With programming, I can usually narrow a problem down until I understand what’s wrong. Marketing felt much less predictable. You can improve your website, rewrite your messaging, or change your pricing and still have no clear idea whether you’re moving in the right direction.
I also realized that I had spent far more time thinking about how the software should work than about how people would discover it.
What I’d Do Differently
If I started the project again, I’d probably approach a few things differently.
The biggest one would be talking to potential users much earlier.
I spent a lot of time developing features because I thought they would make the platform better. And technically, many of them did.
But just because a feature is useful doesn’t mean it’s something people need or are willing to pay for.
I’d also spend less time polishing things that were already good enough.
It’s tempting to keep improving the technical side, especially when that’s the part you enjoy. There’s always something to refactor, optimize, or redesign.
Of course, some things deserve that extra attention. Security and reliability aren’t areas where I’d want to cut corners.
But not everything needs to be perfect before someone can use it.
Final Thoughts
This project ended up teaching me quite a bit outside of programming.
I learned a lot about building and maintaining a trading platform, but also about the difficulties of turning a personal project into something people might actually pay for.
I still find solving technical problems much more enjoyable than marketing, and that’s probably not going to change.
But if there’s one thing I’d take away from the experience, it’s that building a product and finding people who want to use it are two separate problems.
Being good at one doesn’t automatically make you good at the other.
You can check out the project at btradehub.com. Feel free to reach out if you have any questions or feedback.