Top 10 Product Development Mistakes by Early Stage Startups

Since last few years, I had the opportunity to work with several early-stage startups. Amidst the always inspiring energy of the founders, I can see the products taking shape and going big while working on them. However, there are a few things which keep coming back with every new early-stage startup I meet, and they are troubling.

Most startups I meet nowadays, already have an initial version ready, and they want Wikasta to take it to the next level. They have already invested significant time, energy and money on the first version, and they love it. But for some reason, the initial team is not there anymore, and they want a new team to take forward the development of their product. Now here’s what follows:

No proper architecture of the Code Base

When we start to review their code base, we find that the code was never written to scale. The architecture of the code base is not there at all and the code was written in the way “hello world” tutorials teaches. We have literally found more than 80% of the code in single controller/view files.

Coding Standards are not followed anywhere.

There is a lot of code repetition. Because of this, it becomes practically impossible to modify any existing code without the risk of introducing new bugs in unrelated modules.

(REST) API standards are not followed.

I have seen code carrying data for all the entities on the next 5 pages on the frontend, and then using that data across all pages. That API was literally taking minutes to fetch from the backend and render on the frontend. That API used more than 10 tables and several confusing functions on the backend and it was practically impossible to modify.

Redundant Code and Feature never removed

This makes understanding of the code for any new developers even more confusing. There is no updated/relevant documentation in most of the cases, so removal of redundant code becomes more and more important.

Leaving developers tend to write bad code

If the team is small and the code is not being reviewed, which is the case with many early-stage startups, the developers tend to do patchwork for the new requirements and bug fixes, while they are about to make a transition. This is not just true for bad developers, but this seems to be a human tendency when there is no one to look over the work.

No documentation present.

Having said that, it is not always practical to write detailed documentation of every individual feature. But high-level documentation of the system architecture, overall codebase, installation process, deployment process, database schema, and important algorithms should be maintained. It’s worth the time and energy invested.

No Bug Tracking available.

There are always a lot of bugs being found in any software, which are verbally conveyed to the developers. This is the most important aspect for any product, so for an early stage startup, it is a good idea for the founders to keep track of bugs themselves, rather than getting upset with the tech team for not solving a month old critical bug.

Incorrect product vision.

This is the most important of all the points listed in this article. Founders tend to assume they know the most, as it’s their domain. Which is not the case most of the times, everyone learns with time and from their colleagues. This problem becomes even more prominent when the founders themselves are not from the tech background.

Even if a new feature idea is good, it may or may not be a good idea to be implemented as a feature of the product, at that time. For example, the addition of a Facebook like Graph Search in a new social product (which may become a giant like Facebook someday), may not be a good idea right now. Because the resources, research, and experimentation required would be much more and return at this point may be just equal to adding a static search on people by names. And that would be a very quick task.

In short, the product owner should have an open mind for understanding the limitations of technology and team and even if it is done by some other company, it may not be practical for your product at that time.

Bad Choice of Technologies:

This again is a very critical mistake, which the startups seem to be committing too often. The backend language should be chosen based on the product requirement, not just by popularity. Python, although an amazing and popular language, is not the best suited for every requirement. Python’s single threaded nature makes languages like Elixir, Golang, Scala, etc. a better candidate for highly scalable software where you need to use multithreading extensively.

Similarly on the frontend, community support of the javascript framework matters a lot. Using Angular One now is not a good option as 1) there are better alternatives like React.js, Angular 2 and Vue.js available 2) Developers do not prefer to work on outdated technologies.

But the most important part is the database. I have seen startups using MySQL for the first version, just because their first developer “knew” MySQL. However, depending upon the requirements, you need to decide whether you need a relational database or a non-relational. And there is a wide variety of both type of databases, which one is most suitable for your use case has to be carefully discussed. Changing the database later becomes complex, once you go into production.

Horrible deployment practices.

I am not really sure where to being this point from. Not using SSL (it’s free using Letsencrypt), deploying directly using Python’s flask/Django servers without nginx/apache web server, keeping all ports open on the server, are some of the basic mistakes I have seen startups committing often. We have even found databases with open ports and no passwords on servers of startups with critical data of business users. From security to performance, everything is compromised, and generally, the owner of the product doesn’t have any idea what’s going on. This is really troubling.

And that’s why, we decided to start this blog, where we will give you a general idea of what’s right and what’s horrible based on our ongoing experience with several startup products in the industry. We believe this would be a good way to give back to our community and hope to cover as much as we can in our upcoming articles.