The worst entrepreneurial mistake in new tech companies


I have worked with many tech startups over the years. Overall, there has always been one overriding factor that has rocked tech startups – trying to build their app to handle too much upstream traffic.

The goal of every tech entrepreneur is for everyone in the country to use their next product. Everyone is going to make the next star app, like Facebook. To do this, tech entrepreneurs give their tech team an order that is probably their worst mistake: “Making the application capable of adapting to millions of users.”

It might sound like a reasonable request, but I can assure you that this is absolutely the worst possible plan of attack. Programming legend Donald knuth once said, “Premature optimization is the root of all (or at least most) evil in computer programming.”

Why is it?

Optimization – whether it’s making code faster or more scalable (two separate but related optimization ideas) – does several things. First, and most obviously, it takes time. It might sound obvious, but think about this: Every time you spend making your app more scalable, you’re not spending time adding features, fixing bugs, or figuring out how your users can best use your app. At the beginning, these are the most important things.

Unless you have an eight-figure or more marketing budget, there’s a good chance the whole world isn’t knocking on your app’s door (at least during the official launch). What will making your app grow is word of mouth. This only happens if you have precise features, great ease of use, and zero bugs. If you’ve taken the time to make sure your application can reach 100,000 concurrent users on day one, you’ve wasted your time.

The second problem is deeper and much more difficult to see at first glance. When you optimize your code, you usually cement it in place. That is, when you write code, on the first pass, you write it in the simplest way and most conforms to standard system practices (after all, that’s what the system pushes you to do). When optimizing, you need to think about how each element of the system can be changed to support the most common ways of working. Each room must be rethought in order to have the optimal communication paths.

This might sound awesome, and it might sound like I’m reiterating the “time” argument. However, what is really happening here is that you are cementing the architecture of your application and, by extension, its functionalities. That is, if you redesign the architecture of your application so that a certain set of functions are most effective, what if those aren’t the features that users care about? What if it turns out that these features are relatively unused and a new feature is coming?

While a lot of application architecture is aimed at making these other features efficient, that means your new features not only have to be built, but they also have to be built in such a way that they work around your software architecture. The goal of a software architecture is to facilitate future software development, but with premature optimization, the software architecture quickly turns from friend to foe.

In order to optimize, you often need to integrate functionality into the infrastructure. Then, if you want to remove them, you have to re-architect the whole application. It’s worse than rewriting, because you have to do it quickly (you’re a new startup) while the app is still up. This leaves a huge mess in the code and ends up taking years (or more) to really clean up. Sometimes the remnants of these unfortunate premature optimizations are never completely excised.

Here’s the deal – as a new entrepreneur, you won’t reach 100,000 users (concurrent or not) unless the product works well for your customers. And, trust me, your first version habit. If you invest too many resources preparing for 100,000 users instead of being nimble enough to adapt to customer needs, you’ll find yourself struggling with your technology department and you probably won’t even understand why. Features that took a few minutes to implement in the beginning will turn into days, weeks, or months once your programmers have to bypass your “optimization” criteria.

This doesn’t mean that it’s never time to optimize. There may even be a few minor optimizations you can do. The big stuff, however, has to wait. When it’s time you will know it, and by then you will have the resources to do it right, a product that is worth it and a feature set that is. value stone cementation.

Source link

Leave A Reply

Your email address will not be published.