Oh wow what a week. Unfortunately, I'm already late with the episode but it was a very busy week. My son is going to a new daycare and the acclimation starts. So I have to try to combine the settling in and the work. For this reason, I could, unfortunately, record the episode for last week only now because I just did not find the time.

But what happened? In the last episode, I had planned to finish the monitor update and to extend the data output of one monitor. I managed to do that without any problems and even a lot more. When I was at the monitor update I rebuilt this page so that I can use the same component for creating and update. This makes it pretty easy to extend the page if needed without having to change anything in two places. I also did the extension of the data output. Now you can see your Daily Uptime and that for the last 3 months. And since I realized at this point that I need a tooltip and there are no tooltips for React that can be styled properly with Tailwind I built a custom component for tooltips. This was not as easy as you might think. The positioning has to be done automatically so that the tooltip always stays in the viewport. With a little math and checking the viewport, it was relatively easy. Let's see how performant this is in the later course, but for now this is enough.

Since I also talked about having a dark mode in the last episode, I thought we could take this a little further. I once read that there is a group of people who react badly to movements. It's called motion sickness. That means the more you move in the field of view the worse the person can feel. For this reason, I added an option to turn off all animations. This was again easier and faster than I thought. I wrapped the state if the animations are on or off with Jotai in an own store. This state is also stored permanently in MongoDB. So the state is always the same on all devices and after a reload. And when I finished all this I wanted to rework the user settings. There you can change the contact data and also the email address. There is a special feature and you have to confirm the change of the e-mail address because the e-mail address is the complete access to MUUNAD. In the settings it is also possible to change the settings for dark mode, animations, and if the help button is shown or not.

So I managed to do much more than I had planned. That's a fantastic feeling and because everything went so well I dared to tackle a very unpopular topic: Billing.

I thought a lot beforehand about how I would like to design the individual products of MUUNAD. But in the end, I ended up with the classic variant. Fixed packages that are charged monthly. Because even with this there is enough to consider that the customer has a good experience when subscribing to one of the packages.

For the launch of v2 of MUUNAD, there will be a reduced offer of features, for this reason, the prices will not be the final prices. But everyone who books a package now will keep the lower price.

But what is so hard about billing and subscriptions now? Now we start with an upgrade. If the customer has plan A and wants to upgrade to plan B the following has to happen:

Plan A is canceled and billed pro-rata. Plan B is subscribed. Now the billing for the new period has to be done with plan B. Sounds simple, but taking care of it yourself is quite time-consuming.

But then there is another case that is more complicated: Customer has plan B and wants to go back to plan A. A so-called downgrade. Many SaaS providers don't offer this possibility to the customer, because first of all it is very complicated to do this and secondly it means that the company earns less money. But I would like to offer this feature. So what needs to be done?

First, you have to check if the customer is authorized to do a downgrade. This is done by checking if the customer has not exceeded the limits of the plan he wants to downgrade to. If this is the case, the customer can initiate a downgrade. Afterward, the old Plan B will be charged proportionally and canceled, after which the new and smaller Plan A will be subscribed to.

Some of it I have to check myself but most of it should be taken care of by the payment provider. And here, too, I looked at many different providers and ended up with Stripe again. They simply offer the best features and API. So I started to implement the payments with Stripe. I quickly realized that I would have to request the payment details from the customer. This is currently such a big step that I decided not to do it. But why is this such a big step?

There are so many different payment methods at Stripe that it would be a big effort to integrate them into MUUNAD. It would not have to be built for a separate interface, but there are still many and the effort is currently too high for it to be worth it. Currently, a customer can subscribe and later receive an invoice from Stripe by email or download this invoice in the interface of MUUNAD. In this invoice is then a link to Stripe where the customer can then pay the bill. There the customer can also choose any available payment method.

From the user experience point of view, it is probably not the nicest solution but for me, as a developer, it is, for now, an acceptable way to quickly implement billing without having to spend unnecessary time. In the future, however, payments will be better integrated into the UI of MUUNAD when I know what the preferred methods of my customers are.

That's it for this episode. As I said before, this one came a little later than planned because my days are currently very full. Let's see if I can publish the next episode on time again. Until then stay healthy and have a good time!