Some notes from an experienced dev, which might not matter for a small project like that, but well, they help dealing with complexity:

1. When building a project, the first larger goal should not be an MVP, but rather just a "vertical slice". So, you would not start by building addition, subtraction, multiplication, division and then the UI, but rather you'd start by building only division and then a UI for that.
   Once all of that works together and you can actually perform a division from the UI, that's when you can tackle addition, subtraction and multiplication. The benefit is that you don't write a ton of code only to realize that you need to write it in a different way to make it work with the UI.
   Why specifically division? Because it's the hardest. For example, you probably want to report an error when the user divides by zero. Therefore, you want some way of passing errors to the UI. If you started with addition, you might not have realized that.
   It should also be said that you don't have to ignore that you'll need to write three more calculation functions. It is a good idea to take them into consideration for how you structure your code, but you just don't want to invest a ton of time into implementing them, when you don't yet know that your architecture works.

2. With a simple project like that, it's possible to try to plan it out in full, but in larger projects, that's rarely a good idea. You want to plan the next few steps and have a vague idea of where you want to end up, but you'll typically gain a much better idea of what the following steps should be once you've completed the first few steps.
   In particular, your (or your customer's) goals might change, or you might realize that you forgot a crucial step. Or, well, in reality it's probably just lots of detail changes to your plans, because you just had no idea what it would really look like until you had that vertical slice in hand.