SaaSculator part 5 – adding real provider data

journal saasculator

Table of Contents

This is part of a series about building my side project SaaSculator. Each part covers my experiences and learnings while developing. The topics include the development, design, marketing & running of this project. You can find all parts here.

Last time I made the calculator functional. A user can now create multiple products, calculate the expenses for multiple providers and quickly find the cheapest one. But to be actually useful we need the actual data of provider costs, because until now I only used dummy data for demonstration purposes. This part covers the information gathering and real-life data integration.

Making it real

Finding the providers

The first step on getting real data into the app was to find enough payment providers, to justify comparing them. The ultimate goal is to have all of them in there. To start, I researched the most common and popular payment providers for developers and smaller startups. A few names were mentioned on almost all websites such as Stripe or PayPal and some were mentioned most of the times. I quickly had a list of 8 promising providers, which lead me to researching their pricing.

My next realization was that the pricing was not just a simple number that was fixed for each type of transaction and country, but in fact much more complicated than that. The fees usually consist a percentage of the product price and a fixed cent amount. But these fees could vary quite a lot for different credit cards (foreign / international), payment methods and country of origin of the seller. Let me give you an example for Stripe:

U.S. Stripe

  • 2.9% + 0.30$ for U.S. cards

  • 3.9% + 0.30$ for international cards

European Stripe

  • 1.4% + 0.25€ for European cards

  • 2.9% + 0.25€ for international cards

The differences among payment methods (Alipay, EPS, Klarna, etc.) were even bigger.

Future considerations

While I want to make the tool useful for users all around the globe, it was outside the scope for now to distinguish between pricing for different countries. The goal right now is to get it up and running as quickly as possible. To just ship it. This also applies to the fact that the customers location or other payment methods make a difference, as stated above. I made a note in my list of future features and decided on using U.S. prices for U.S. cards for a start.

Even though leaving all this information out seems to go against the purpose of the product, it is a deliberate decision of me to keep it as simple as possible in the beginning. Because introducing this much complexity in such an early stage, will just open more doors to features that need to be done and push my ability to launch further back. In order to handle these different pricings, I would not only require the user to specify his location, but also how his customers are distributed. Are they from the same region or international? How is the split? Which payment methods do they use?

Imagine you had to enter separate numbers for each payment method and customer region available. You would probably close the tab without even giving it a shot. At the same time creating a UI with so many options, without sacrificing usability is extremely hard.

I think it’s important to find the right balance of functionality and ease of use. Right now, simplicity outweighs the extended functionality of adding all these features. That’s not to say they will never be added, instead they are just not the right thing right now.

Real data & real bugs

After having compiled the list of my payment providers and their prices it was time to enter them into the app. Because I already had a simple data structure in place thanks to the dummy data, that step was done in a few minutes and the tool started to spit out helpful numbers.

While entering the data I noticed a bug in the calculation of the cheapest provider, though. It occurred when you have multiple products and then delete a product. Instead of updating the cheapest provider in the top card, the values stayed the same. It took me a while to realize that the problem was in the way I structured the data together with Vues lifecycle. I had a computed property to calculate the earnings for each provider, which did not update after a user removed a product, because it did not trigger the computed property. My quick workaround was to use a watcher on the number of products and make use of Vues nextTick() to trigger an update. While I should certainly rethink the architecture in the future the workaround was good enough for now, this is what did the trick for me:

products(products) {            
    if (products.length != this.productLength) {
        this.$nextTick(() => {
            this.productLength = products.length;
        });
    }    
}

The tool was now functional and with real data, which meant it could be released into the wild open sea that is the internet. Even though its functionality is quite limited at the moment, having it out there helps me with two things. First, it prevents me from perfectionism. Otherwise, I will always find flaws and things that could be improved, before eventually shipping it, because nobody wants to create a broken product. But having a great product that you never ship is not going to help anyone either.

Second, it forces me to make smaller but complete features in the future. Because when its published you can’t just add functionality without also thinking about how to integrate it into the design. You have to completely finish the feature, its looks and its integration in the existing website. But because all of this takes work (and time), the only way to speed it up is to make the features smaller. Hence more but smaller iterations.

So, the next step is publishing it.