Not in House: On Reinventing the Wheel

Reading Time: 8 minutes

As a bootstrapped founder, you will have to be scrappy. You will want to spend as little as you can on expenses, particularly when you’re just starting. So anything you need to do, you want to do by yourself. Anything you need to use, you will want to build yourself. But in my experience, a few things should be excluded from that: if you’re not careful, they will blow up in the future big-time, putting the whole business at risk.

Don’t Build an Authentication System Yourself

I remember building my first authentication system many years ago while building the MVP for a prior startup I was involved in. At that point, I was building a lot of software using Node.js, and I was aware of several libraries that would allow me to create this myself. There weren’t too many requirements initially: customers should be able to sign up and log in using their email and a password, and that was it. My first mistake was to not spend enough time looking into what authentication really encompasses. It’s not just an email and a password, it’s a whole web of interconnected processes and assumptions.

First, I noticed that I needed to save my users’ passwords. Having been working in software engineering for a while, I knew I couldn’t just keep them as plain text. I looked for best practices and found that I needed to implement password hashing and salting using the bcrypt library. I understood that I needed to do this, but I didn’t understand why. In the end, I just followed best practices. This is not the level of security your customers will or should ever be happy with. You are dealing with their secret information. You should know that you’re doing everything to keep it safe.

Keeping the personally identifiable information of your customers in your database is a giant risk, and will make your system a target. There are whole companies out there that take care of the security and privacy requirements of authentication, with teams of security experts making sure the data is inaccessible to those who shouldn’t see it. 

Other things pointed at the fact that I had bitten off more than I could chew. After a few days of development, I realized that I would need to build a password reset process for users to recover their passwords. All of a sudden, I needed to integrate transactional emails into what was supposed to be an isolated system. Then, I figured that we were building a B2C product, which might mean that customers would want to log in using their existing social providers: Facebook, Google, Twitter, and others. It took me almost a week to understand and adequately implement just a few popular OAuth2 providers as a source of authentication.

Building our authentication system made sense at first before I had realized the complexity I was facing. Even if I were to build it myself, it would not be simple, and definitely not easily maintainable. There were libraries and plugins to make it easier, but it still meant a lot of work that could have gone into building the unique core features of our product.

Ever since that experience, I recommend using Auth0 and their Identity-as-a-Service offering from the beginning. They have a free plan that will last you a long time without needing to pay, and even with thousands of customers, it will still be less than $100. You will save weeks of development time, and it is a double save: you get to work on your core product, and you don’t have to re-invent the wheel. And your customers’ data is in good hands.

Don’t Build a Payment System Yourself

It’s bad enough to have personal information in your database, but having credit card information touch your system gives bad actors a strong incentive to steal that precious information. Use a PCI-compliant processor where the card information never gets transmitted to your servers, like Stripe. The great benefit of this is that payment processors have built-in fraud protection, which will make it easier for you to avoid troublesome customers.

At this point, most founders are already aware that they need to find a suitable solution for payments, and rarely roll out their own. I still hear some first-time entrepreneurs complaining about the fees involved, which can often reach 3-5% of the transacted payment. While this is a lot, it helps to think of this as an infrastructure tax for doing business on the internet, a way to make sure that your recurring revenue will be reliably captured month after month. 

Don’t Build an Invoicing System Yourself

In the beginning, it might be easy just to generate your own invoices, as you have just a few customers and likely only a few plans or prices. But come tax season, you will find out that you should have added a particular field, for certain kinds of customers from a specific country. Invoicing is complicated, and there are dozens of companies that focus on offering a globally usable invoicing integration into Stripe alone. Leave financial things to the experts, and focus on your strength of providing a great product to your niche audience.

I made this mistake with FeedbackPanda, and never rectified it. It worked well enough, but any change to the system was a pain. Like with the authentication systems I had built myself before, I was not aware of the complexities that awaited our business. Most of them were not our own requirements but of a regulatory nature. We had registered our business in a country where invoices need to be in numerical order, with no gaps. They need to clearly state postal addresses, and they need to have valid and appropriate dates as well as specific legal terms. 

And then there were taxes! As a German business selling to customers all over the world, we needed to calculate taxes differently depending on the location of every customer. Some had to pay Value-Added Tax, but only if they didn’t have a European, non-German VAT ID. The complexity of this resulted in me building a tax calculation system that was very brittle. With tax rates changing every now and then, it also needed to fetch the most recent tax rates every day from a European VAT rate API. 

None of this was relevant to the core audience of FeedbackPanda, who were online teachers. They needed help with their daily operations. The time I invested in building the start-of-year invoice number overflow logic (where “#2018-4459” would be followed by “#2019-0001” on the first invoice of January 1st) alone could have meant a few bug fixes or work on a teaching-relevant feature.

It was such a waste of time.

The Mental Trap of Building Things Yourself

As developers, we are very likely to think that, “if I build it myself, I’ll understand it better,” and it’s true. We do benefit from learning how to solve these problems, to a degree. The problem is that in a bootstrapped business, learning-on-the-job should always result in something highly beneficial. Learning how to build an authentication system like tens of thousands other developers have learned before won’t make your business any better. 

Wasting time on building something that others know the complexity of while you are entirely unaware is a foolish thing to do. Your core product is where your expertise lies, it’s where you know how much is “enough,” and which steps are required to reach that state. You won’t have that level of insight into non-core parts of your service. Use the services of experts in those fields.

Wasting time on building something that won’t improve your industry expertise will hurt your business. You’re collecting unfair advantages along the way. Everything that makes you more of an expert among few others will set you apart from your competition. Building the world’s 15.000th invoicing module won’t get you any closer to that goal.

The worst part of building things that you don’t need to build is that this is distracting you from the primary mission of your business: creating a self-sustaining value engine that helps your customers solve their critical problem. If you’re not focusing on making that a reality, you’re straying from the path.

Building things that you shouldn’t build is often is the result of a grandiose underestimation of the time required to get it right enough. For everything that sounds simple enough to build yourself but has many SaaS solutions out there, ask yourself if maybe, the people who pay for it know more about the complexity of that feature than you do at this point.

A (Mostly) Unbiased Risk Analysis Framework

Let’s look into how you can figure out if a feature that you need is a candidate for building it yourself or spending money on an existing SaaS solution.

I will try to give you the least biased perspective on the risks for either choice. They originate from my experiences, reflections, conversations with other founders, and stories I have read on the topic. For every point, make sure you find your own opinion and weigh it accordingly.

If you want to make this a data-driven choice, make a list of all the risks of building and all the risks of buying, then see which list is longer, and take the shorter option. 

The Risks of Building This Yourself

Building things yourself opens up the possibility of waste and distraction. Note down all the risks that can negatively impact your focus on the core of your business.

• Unexpected Complexity. Will building this feature uncover a different order of magnitude of development cost? Are there hidden costs in the amount of time you will have to spend on this? Can you be sure that there is a ceiling? What parts of the feature do you think could turn out to be unusually complex? Have you checked for reports of edge cases?

• Unexpected Compliance. Are there regulatory requirements for this feature that you might not be aware of? Are there hidden costs in terms of money and effort to be able to comply with them? Have you checked the kinds of compliance that solutions in this space openly advertise? Do they apply to your solution too?

• Distraction. Will building this feature distract you from your mission, or will it lead you to it? Is your focus going to be on the core value generation while you build this?

• Roadmap littering. Will this feature add more things to your own roadmap that push the important stuff further out? Is it worth delivering other features later than anticipated? Are your customers okay with that? Are you?

The Risks of Not Building This Yourself 

Buying things makes your systems more fragile and can result in a lack of control. Note down all the things that might be a risk to the operations of your business.

• Unexpected Downtime. How will you react to outages and service degradations? Will your customers understand this? Do you have ways to reach customer support for the service you’re buying? Will this cost extra? Is trusting that “things will continue working” the only way?

• Unexpected Implosion. What will you do if this service is closing, sold, or pivoting to a different product? Do you have a reliable way of continuing to use it then? Will there be alternatives? Are there migration paths? Can you build abstractions that are good enough to change the underlying service in a hurry?

• Roadmap Misalignment. Does the service have all the features you need now? Does it have all the feature your will need once you scale? If they don’t, can you be sure they will have those features at that point? Is there a chance their roadmap will undergo significant changes in the future?

Finding a Balance 

With risks on both sides, how can you make a good decision here? I recommend erring on the side of caution. In many cases, I found that to mean buying a solution rather than building it. Established SaaS businesses had run into a lot of the problems that you might encounter long before you even thought of adding this feature. 

Know what you’re worth. Do the math and weigh the risks carefully. Find the big players in the field that you consider building a solution for, look at their feature set, and see what you think might come back to bite you if you were to build it yourself. Then, plan how long this would take you to engineer. Think of where you’ll be in 5 years. Will this solution still suffice? Or would you rather have other people iron out the kink s and bugs of that part of your solution?

Buying SaaS solutions won’t make your business any less sellable either: acquirers have come to understand that the value of a company is in their core offering. Any non-core software they would need to maintain is a liability. Your business will be better off without hard-to-maintain components that other people have solved much better and cheaper somewhere else. 

In general, if it’s not a part of your core business, consider buying a solution. This means that you will have a large number of small services you’ll be paying for over the years. That’s fine. Every service you pay for is an overall reduction in the complexity of your solution. Your product should consist of the minimum logic to maximally solve your niche audience’s most critical problem. Leave everything else to those who care more about addressing issues like authentication, payment, and invoicing. Concentrate on the things that make your business unique.