We all have our way of doing things, but there are still some general mistakes that we can avoid.

Here are the ones I've encountered most frequently:

1. Using over-complicated tech stacks

You can build an app that handles millions of users, using a simple tech stack.

Let's take a look at what HEY is using:

That tweet belongs to David Heinemeier Hansson, the creator of Ruby on Rails and the founder of Basecamp and HEY.

As you would expect, there are lots of opinions in the comments:

If you're skeptical about MySQL, you should know that Uber switched from Postgres to MySQL in 2016.

And sometimes, it's perfectly fine to use vanilla JavaScript.

The idea behind technologies like React and Angular is to use them for large web applications where you need to have states synchronized across many different UI elements.

In many cases, something lightweight can be more appropriate.

If you're not working on an application used by millions of people, you probably shouldn't focus on separating your app into microservices just yet.

You can take care of that later, when your application starts getting millions of users.

Surprisingly, a monolithic architecture can still handle 6-8 million users if you scale it and optimize it correctly.

We should focus our energy on delivering a better experience to our users, not to ourselves.

2. Ignoring Accessibility

We should only build websites that are inclusive and accessible to everyone.

There are six main key areas of disability:
• Visual
• Hearing
• Mobility
• Cognition
• Speech
• Neural

I learned a lot about Accessibility from this article written by Addy Osmani.

Accessibility legislation for websites is still in a gray area, but this might change in the near future and companies that do not comply might face large fines, similar to GDPR.

3. Ignoring cross-browser compatibility

Let's have a look at this chart from Stat Counter:

Google Chrome has a 63.6% market share.

Checking your website only on Chrome means you're leaving out 36.4% of your users.

The new version of Microsoft Edge is using Chromium, but it doesn't mean that your website will behave exactly the same in Chrome and Microsoft Edge.

Safari has a market share of 17.7% and it's using WebKit as a rendering engine.

And Internet Explorer is still here and the Service Manual from the UK Government still expects you to test your application in Internet Explorer 11 in 2021.

There is no silver bullet or magical solution for cross-browser compatibility, you still have to test.

Some testing tools might impair your cross-browser testing efforts from the start.

For example, Cypress doesn't work on Safari and Internet Explorer and there is no sign that it will ever offer support for them.

Since I work at Endtest, I'm very familiar with cross-browser testing, since our platform is used by thousands of developers to build and execute automated tests.

The best web developers I know always make sure that their applications work on all major browsers.

4. Working in a bubble

Developers can build an app for the Financial sector without knowing or learning anything about that particular domain.

It's easy to get away with this because everything is broken down into small tasks and the business logic is handled by a Product Team.

Taking the time to learn more about the domain and the users can help you deliver a better experience to them.

Start by discussing more with the Product and Sales teams, you can learn a lot from them.

5. Blind trust in open source

Open source is by far the best thing that has ever happened in the software industry.

The problem is that some companies are now using the term as a Marketing technique.

Some companies noticed that developers have a low tolerance for proprietary solutions, so they just rebranded themselves as open source.

This tends to give them a free pass to promote their brand on open source communities, to avoid security assessments and to fly under the radar of developers who might not realize that there is a for-profit corporation behind that solution.

Some of your favorite open source solutions are owned by for-profit corporations:

1. npm, Inc. is the for-profit company behind npm.
   They raised over $10M and got acquired by GitHub in 2020.

2. Nginx Software, Inc. is the for-profit company behind Nginx.
   They raised over $84M.

3. Gatsby, Inc. is the for-profit company behind GatsbyJS.
   They raised over $46M.

A large number of open source solutions are actually developed and maintained only by employees, with no active community behind them.

And some for-profit corporations go to great lengths to give the impression that there is an active community behind their solution.

Remember how Kevin from Home Alone created the illusion that there were people in the house to scare off the burglars?

There are plenty of unethical techniques used in that space, such as hiring people to sit on public Slack and Gitter channels to defend that solution and dismiss alternative approaches, or offering small financial incentives to tweet about that open source solution.

Dual licensing isn't the issue here, that's a solid and ethical business model.

The real issue is misleading users into thinking that the open source solution is built by a community and its popularity is not artificially inflated.

It's always a good idea to investigate an open source solution before using it, as most of the hype might be the result of an obscene Marketing budget.