9 common mistakes developers make

In the startup world today, we’re used to tradeoffs, especially in the service of speed. And developers – who, like just about everyone else on the team, get into a habit of putting out fires all day – can get caught up focusing on the wrong thing and consequently, create problems for the company.

In order to find out what kind of mistakes are most common, I asked a panel of nine successful entrepreneurs from the Young Entrepreneur Council the following question:

What’s one common (and easily avoidable) mistake startup developers make?

Here are their top picks.

1. Building Based on Their Own Problems

Most startups (at least successful ones) tackle real problems. The issue with that is startups tend to project personal problems as community problems. In turn, they build their products based on their own needs and hope to solve the community’s problem. That is a recipe for failure.

Startups need to validate that their problem really exists in the community. Furthermore, they need to understand why the problem exists for that community. The only way to accomplish these tasks are by talking to the community and validating the problem and a plan to fix it.
– John Jackovin, Bawte

2. Building Too Many Bells and Whistles

There is a lot to be said about a minimum viable product. Build it as simply as possible, and begin testing your assumptions as soon as you can. Start with a small group of beta testers and, using their feedback (and only then), begin to incorporate some of those bells and whistles.
– Peter Awad, GoodBlogs

3. Creating Inflexible Code

Although you don’t need to initially develop a platform that is fully scalable from the get-go, it is critical to ensure your platform code will support scaling in the future, rather than starting to consider it once you’re successful.

Modifying inflexible code that is actively being used by clients can be very frustrating and will slow down the growth of the company when it is most important.
– Fehzan Ali, Adscend Media LLC

4. Deploying Early

The startup world encourages fast deployment. It is important that businesses launch products to get feedback sooner rather than later, but a launch-now, fix-later attitude is foolish if your product comes with too many bugs.

As you grow the business, your customers expect more, so your deploys shouldn’t be full of holes. Be prepared to deploy a couple of days later than scheduled, so you can have a bit more time to fix any bugs that will impact the user experience and how users see your brand.
– Danny Wong, Blank Label

5. Caring Too Much About Code

It’s more important early on to solve a customer’s problem than to write code. If you focus on the customer, it will be a lot easier to get the code right because you know what your customer cares about.
– Wade Foster, Zapier

6. Not Getting Involved in the Business Aspects

Not getting involved in the “business” aspects of the company or misunderstanding the company’s customers is a common mistake. Products are not companies. Understanding how the product aids a company’s overall objectives, strategy and customers is key to successful product development and deployment.
– Panos Panay, Sonicbids

7. Trying To Be Everywhere at Once

When launching a product, it’s very easy to think you need to be everywhere from the start. The smart approach is to build on a few platforms — or ideally only one. This way, you will build a better product and avoid spreading your team too thin.

For some companies, it might be desktop versus mobile. For others, it might be disregarding Android to focus on iPhone. Figure out where you want to shine first and then optimize!
– Aaron Schwartz, Modify Watches

8. Mixing Departments

The first thing a startup should do is separate innovators from people who run the book. Don’t ask the tech geeks to watch financial statements.
– Yuriy Boykiv, Gravity Media

9. Planning Based on Ease of Code

Before you even start the development process, there is always a planning process. While planning, it is common to think through the ways something could be implemented and plan out features based on what seems feasible in code.

I say plan everything as if there is no code involved, and then go back and solve the puzzle of making it work. The question should never be, “What is the easiest way to make this work?” Instead, you should be asking, “What is the easiest way to make this work for the user?”
– James Simpson, GoldFire Studios