Hey 👋

Hey there, I’m Ben, the founder of Mockernut Ventures! MV is the holding company for all of my indie startup ideas and what this blog is named after. Why do I have a holding company? Well, I quit my full-time job at a big tech company a few months ago and committed to building 12 startups in 12 months and needed an umbrella to cover all of those businesses.

This is my second month in the 12 month journey of startup creation. With that, I hope you enjoy this post about the second month of building startups!

New Month, New Priorities

After finishing month 1 by shutting down my 3D printing startup that made some money but wasn’t a good fit for my lifestyle, I decided it was time to build a startup idea that aligned more closely with what I enjoy doing. That meant focusing on something that didn’t involve delivering physical goods to humans, a task I had spent the last 7 years of my life automating at various tech companies.

After some thought and looking through my list of ideas, I decided on Simple OTP, an authentication startup and spent the last month building it from zero to one. You might be asking yourself: “why launch yet another authentication company? Competitors already exist.” Well, as it turns out, there are a few reasons why this made sense to focus on as my next idea:

• Competitors existing isn’t a good enough reason to not work on something. It means there’s a pre-validated market already there which can be an advantage.

• My thinking at the time was: “I can provide a better customer experience and faster authentication using newer algorithms for less money than anyone else is charging.” And, especially now that I’m done building an authentication service from scratch, the cost of operating it is very minimal and there’s no reason (besides greed) to overcharge customers to the extent that it is being done today.

• Most importantly, and getting to the point of the title: even if I don’t get a single customer for Simple OTP, passwordless authentication is something that I need for every single one of my startup ideas. Building authentication upfront means that I never have to worry about it again.

You might recognize that this is the classic “build vs. buy” decision point. Here, I chose to build. Why did I choose to build? Because building this particular idea means that I can’t lose. And why can’t I lose with this idea? Read on!

All I Do Is Win, Win, Win No Matter What

The first reason this idea is a win is because it saves me money in the long term - DJ Khaled is right, I do have money on my mind. Of course, I could use a competitor’s product instead of building, but such a move would require me to:

• Spend thousands of dollars per month for only a few thousand monthly-active-users (MAUs).

• Sell user data to a 3rd party company who may decide to sell user emails to the highest bidder (looking at you, Facebook and Google Login).

• Lose out on flexibility: if I ever want to change password encryption algorithms, host the auth server myself to own my own user data, I can’t because I don’t own the authentication code.

• To that end, be okay with vendor lock-in:

  • Auth companies use proprietary authentication libraries that are not compatible with each other. Having to switch libraries later will waste time as I’ll need to replace all references of the old library in my frontend and backend apps.

  • Companies that offer social login, especially Facebook in my experience, are known to deactivate apps that they think are abusing their impossible-to-understand ToS and are notoriously difficult to get in contact with. At a previous employer, Facebook decided to turn our app off for some reason, which caused major issues with signup conversion. We couldn’t do anything but spam Facebook with support requests until they finally relented and re-enabled the app, and I don’t want to put myself in that position again where someone else controls the ability for my website visitors to sign up.

Given the above problems, I decided to build. Also, just by building something in general, I also achieved some secondary benefits that I wouldn’t have otherwise. These benefits were only achieved now because last month’s idea lent itself to no-code, so I didn’t write any code - this is the first month where I actually wrote software, because it’s impossible to no-code your way into an authentication product. Here are those secondary benefits of building something:

1. I didn’t have a decent landing page template. Now I do. I can clone this template in 30 seconds and change the wording for the next idea.

2. I had never added a payment processor into an app before. Now I have, and I’ve already ironed out all of the “gotchas” so the next integration will go that much faster. I’ve also educated myself on sales tax law and found out the common advice of “just use Stripe” doesn’t make any sense for Software as a Service (SaaS) vendors. I’ll expand more on that below.

3. I didn’t know anything about Tailwind CSS, now I have prebuilt components I can use in any of my apps to make development faster.

4. I hadn’t deployed a backend web service in a long time, and by building with the latest version of Go and writing a CI pipeline script with GitHub Actions to deploy AWS Elastic Beanstalk, I was able to put together a template repository that I can quickly duplicate when starting on a new project.

I estimate that by having all of the above in place I’ve saved myself 2+ weeks of development effort on any future idea, so this will continue to pay dividends for a long time.

Speaking of dividends and percentages of revenue, let’s talk payment processors.

I Got Money On My Mind

What do you do when you need to collect money for your SaaS company? You integrate a payment processor. Which one comes to mind first? That would of course be Stripe.

Indeed, the common advice in startup land seems to be: “just use Stripe” or at a minimum “just use Stripe, and only switch to another payment processor later when you start doing real revenue.” Unfortunately, if you want to comply with the law without jumping through a million hoops, “just use Stripe” is terrible advice in 2023. Don’t get me wrong, Stripe is a great product overall and their API docs are amazing - but their Tax offering is just not good enough for entrepreneurs who want to sell globally today.

Why is this? We have to look at history. When Stripe was founded approximately 13 years ago, sales tax law for online products was still being defined. Countries hadn’t caught onto the SaaS craze and you could basically just register for tax where you lived, collect payments globally, and not worry much about it as it was a “gray area.” Oh boy has that changed, and not for the better:

• Sales are moving to be increasingly global as the median household income improves worldwide. As a result, every country in the world now wants a piece of the SaaS pie, and they have laws to make sure they’ll get that money from you. It’s an absolute nightmare to try to understand and comply with all of these different laws. One payment processor has written an absolutely great tax agony around the world guide that explains just how much of a pain this is in 2023.

• Some countries are more difficult than others and don’t even apply limits on when to start collecting sales tax. The US is mostly reasonable about this - most states require $100k or more in sales (or some high number of unique purchases in a given state) before you need to start remitting sales tax. So, if you have a product that only applies to people living in the US, you’re probably fine to use Stripe at the beginning.

• However, the UK requires you to register and remit sales taxes for a single sale regardless of the order value, even if you just sold a single $1 stick of gum to someone in London who happened to find your website randomly. I don’t know about you, but I don’t specifically advertise my products to US customers - I want to sell to everyone and capture as much revenue as possible. Given that, do you really want to go to sleep at night worrying about if your sales tax registrations are up-to-date based on whichever customers happen to find your website? I don’t, but if I had stuck with Stripe I would have been in that position.

• Some countries like the US require sales tax for any kind of SaaS transaction, whereas others only require it for B2C transactions (B2B are exempt). Unfortunately, Stripe doesn’t have the ability to require collection of a VAT/Business ID number from customers (it only shows the field as optional on their self-checkout page), so you’ll have to either build a custom payments UI or chase down customers after the fact if you want to prove that a given transaction is truly a B2B transaction when using Stripe Checkout. Is the law really going to come after you for this? Probably not if you’re a small company, but why take the chance? For the same reason, it’s a good idea to pay your income taxes every year if you don’t want to get into legal hot water.

So why is Stripe and Stripe Tax not good enough in 2023? It costs you more money per transaction to enable Stripe Tax (an additional fee is charged) and it only solves part of the problem! Stripe Tax will happily tell you how much you owe in tax globally and give you a nice report to work with every quarter, but:

1. You need to manually add every single tax registration that you have to Stripe Tax for that report to be correct. This is particularly problematic because if you’re not carefully watching your sales, and someone happens to buy in a “difficult” country like the UK, you may not even know that you need to add a new registration => you’re now out of compliance with the law without even trying, congratulations.

2. Most importantly, Stripe Tax does not remit taxes for you. What does that mean? Every single quarter (or every month, or every year - it all varies on the jurisdiction and how much revenue you’re doing) you will have to log into different foreign government websites and send them the sales tax that you had to legally collect from customers in their region if you happened to make sales that went over their threshold. Again, if anyone in the UK buys a single product from you for example, you’re already over the threshold because there is no threshold and you need to start worrying about this.

If this all sounds like a nightmare to you (it certainly did for me), Stripe isn’t a good choice. You instead need to use a Merchant of Record who will basically resell your product on your behalf and take care of 100% of the sales tax obligations for you. No need to register for tax at all! There are two common MoRs that a lot of SaaS entreprenurs use:

1. Lemon Squeezy: I like this one the best. It’s a relatively new product and they’re still ironing out some bugs/have a few communication issues, but I’ve found their support to be helpful and they use Stripe behind the scenes for all payments. This gives me confidence that credit cards will be charged properly since Stripe has perfected this. They also have useful features like a free affiliate program for your website, free cart recovery automation (Stripe just says “configure a webhook URL and handle cart recovery yourself” — so this feature is much better than what Stripe offers), and their admin portal is clean and operates just like Stripe (it has test and production mode).

2. Paddle: I actually tried to integrate with them first, but their support flagged my website for some reason and they were very picky about asking for a bunch of documents before I could get started. I didn’t feel like dealing with all of this, so I decided not to work with them. I’ve also heard some reports of their support being generally difficult to deal with, but I have no firsthand experience with them in production and your mileage may vary.

What’s the downside of a MoR? Well, their fees mainly. Lemon Squeezy and Paddle both charge a minimum of 5% per transaction, which is quite a bit higher than the standard 2.9% + $0.30 Stripe charges. Lemon Squeezy also charges a bit more on top of their 5% per transaction fees for PayPal transactions and international, so you may end up paying closer to 6-7% in fees for some transactions. Paddle offers cart recovery, but charges extra for it whereas Lemon Squeezy does not, so you might also pay more than you bargained for if using Paddle.

However, when evaluating using a MoR at all, you have to consider the whole picture: is it worth paying a few more points in revenue to never have to deal with sales tax again, plus not having to build cart recovery or an affiliates/referral program yourself?

I’d say hell yes to that question, and for that reason, I ditched Stripe and used Lemon Squeezy for the Simple OTP launch which went swimmingly. I’ll continue to use them for future products unless I happen to come up with something that is “US only.”

That’s All For Now

I hope you enjoyed this month’s progress report. See you again this time next month - I’m sure I’ll have even more to write about after launching my next idea in the network security space.