Code Decisions Matter

I get a ton of questions on startups.  One of the questions is, “Do code decisions matter?” Typically, this is around language, so I tend to answer the question, “do languages matter?”  The answer is, “no, languages that you use do not matter to an end customer” on the surface.  Customers don’t care if you use JavaScript, python, c#, Java, etc.

However, there are some code decisions that do matter.

Algorithms matter.  Choosing to use algorithms that perform well matter.  Sorting is the classical example, so let’s look at it.  I’m not a sorting guru, but I do know that some sorting algorithms work better in some scenarios over others, it just depends on the scenario.  I’d look at the scenario and see if there was a better algorithm to use.  I once had to create an algorithm that on the surface looked to be order n cubed, yuck.  I started looking at my testing scenario and N would always be small, so I just said it was good enough and moved on.  It was good enough, so did it really matter?  No.  I was lucky as this isn’t typically the case, so be careful and know your scenario backwards and forwards before making a decision.  As I often say, sh*tty algorithms are sh*tty no matter what language you use.

Decisions matter.  Languages don’t matter, but decisions on direction do.  I’ve been helping some startups recently and I’ve come across a trend.  Let’s assume that you build a product that solves a customer problem.  As you develop this, you determine that there are other customers that could use this similar/same solution.  There are two general solutions to this

You can require that each customer have their own infrastructure to support a solution.  This is doable, but it basically requires that you create a solution to the customer showing up with a credit card where you create a silo’d system for each customer.  The customer gets their own complete copy of an infrastructure.  For this to be efficient, you either need to tie yourself to a cloud vendor and create databases as well as web interfaces, thin clients, fat clients, and the necessary infrastructure. While this works, I still view it as sloppy.  You can end up with silos of code and databases, which makes things hard to keep constant.

Another solution to this is to build up a Saas solution for this that falls into multi-tenant.  Tenants are sets of customers, think of them as a business and their customers.  In this scenario, you build up a solution from the database upwards where one solution handles multiple “tenants.”  This starts at the database level as well as in the application.  In this scenario, a customer comes to a solution, hands in a credit card, walks thru some setup options, and boom, the app is up and running in their world.  This is what you want.  Why do I know this is a problem?  I’ve had this problem in the past.  I’ve had this issue in the past at Marketlynx.  We realized the problem early on, and pivoted to produce a product that ran across multiple customers.  To make this work well, don’t think about putting specific code or reports in for a customer,  think about how to take a client request and turning it into a feature that solves multiple customer problems.  You will never have two customers that use the exact same code, but you can build code that solves the problems of two, or more, customers without having specific code that is only used by one customer.  I’ve done this in the past and it isn’t hard.  You have to break out of the idea of being a waiter trying to provide a diner what they want, you need to think about how to handle customer needs in the whole.  How can one request be used to solve multiple customer problems?  Think about this and how you can satisfy multiple customer problems in one scenario.  A user shows up, puts the credit card in, answers some questions, and poof, they are up and running.  You don't have to depend on magic to happen behind the scenes since the infrastructure is already setup.  This is the best way to scale since everything is already setup.  You just need to be smart regarding how to handle customer specific requests.

Good luck going forward with your startup idea!