It started off as a weekend exploration out of curiosity in the summer of 2020. However, I have continued working on it on the side ever since. One reason for that is because I love the psychology and probabilistic nature of trading. I have also kept learning and improving my product skills, be it UX design, systems design and architecture, roadmap management, prioritization, pivoting, QA, performance, or scaling.

What is unique about this type of product is the absence of customers (at least in its current form). The market is my customer. The goal is to build a reliable and performant infrastructure, along with a profitable strategy. Knowing if it works is simple: either run the bot live or through a simulator. So, even though I have no public product and no customers, I am able to receive relatively fast feedback and iterate a lot.

I have built a lot of things, pivoted multiple times, and made many mistakes. However, I continue to learn, so I'll just cover a few lessons I have learned.

1) Don't over test before having a stable version

I've made this mistake twice, actually. It goes like this: I get a new idea about how to operate the bot. I design the flow on paper. When I am pleased with it, I implement it (usually affecting more parts of the system than initially anticipated). I jump straight into writing unit tests, which takes a lot of time and, frankly, I find boring. Fast forward a few months, I realize my solution is missing a few important use cases, and I have to go back to the drawing board.

Takeaway: Skip automated testing altogether or keep it to a minimum when building something with unclear requirements. Sometimes, it is appropriate to write tests. For example, if you wrote a function that calculates linear regression parameters, then using unit tests is appropriate. The expected behavior is known and clear. When it isn't, defer testing. Instead, build it and test it by using it. This is even more true in Frontend. Even if a component does exactly what it's supposed to do, the user experience can still be bad. That is something you can only confirm when you use it.

2) A bit of research before designing your data models goes a long way

Let's take, for example, integrating with banks. Say you need to integrate with 10 banks and require the following endpoints: getBalance, makeTransfer, and payBill. Being lean is great, but there is such a thing as being too lean. If you only look at one bank and build your entire design based on their documentation, you might be unpleasantly surprised to find out that their specifications are quite different from the rest of the banks. To avoid this, without falling into the other extreme, randomly pick 3 out of the 10 banks, study their documentation, and design based on all 3. Then, you can validate your design by looking at 2 more banks. By doing this before starting to implement, you reduce the chance of overfitting to one specific bank without having to go through all 10.

3) Ask better questions, avoid fake productivity

I have been working on this for 3 years now. Even though it wasn't full-time, I believe I wasted a lot of time by not asking the right questions. The biggest example is focusing on implementing different trading strategies (and unit testing them) before having a reliable testing mechanism. By the way, I am referring to behavior testing as in "does this strategy actually work?". It sounds stupid when I say it now, but I had to run the bot in production with a small amount of money to test a strategy. This is bad on many levels. First, it is very slow to see any statistically significant results. Second, I am risking real money. Third and most importantly, I don't have a full picture because even if it performs well, that's just one sequence of possibilities amongst many others. I could very well just be lucky and run my test in a good market or winning asset during that period. It doesn't tell me the real performance of the strategy.

Even though I was working hard, I wasn't making progress. Obviously, it's easy to say this in hindsight. This is a skill you learn over time.

4) Delegate non essentials

This is related to the previous point but looked at from a different angle. I built a landing page and a reporting web app. I went through designing them in Figma, writing all the code, and making sure they're responsive and everything. However, if I'm being honest with myself, that was completely unnecessary.

Sure, I improved my skills and really enjoyed designing the UX and UI for both, but it doesn't justify working on the wrong thing. It is about the ROI of my effort. With limited time, I should be very cautious of scope creeps, especially when there are alternatives. I could have used Framer or Webflow. I think a good rule of thumb is to start by asking, "Is this essential to the core product?" and if not, find ways to outsource it, use existing tools, or not do it at all.

• Finish building the core functionalities and stabilize the production version.
• Explore machine learning and how it can improve my current solution for certain pieces, such as the simulator.
• Currently, the landing page is not optimized at all, whether it's performance or SEO. A cool "kill two birds with one stone" idea is to write a blog article showing how to optimize that landing page.

PS: I currently have a landing page with an actual service offering. It is technically possible to get the service, but as I mentioned earlier, this is not the focus for now. Plus, in terms of sales and marketing value, the page is quite basic (if that). It was a quick version built in a few days just to have an online front. I have a Trello card with a lot of details and ideas to rebuild a legit landing page. However, like I said in lesson 4, this is not a priority so it shouldn't be done for now.