Common issues with web projects

Here is a list of very common issues I came across in the development of web projects, and how to (hopefully) avoid them. As you will see, many of them are not really related to technology.

Needs not needed

Here is how you could react to such a behavior:

  • If your client has enough money to build this giant system, and you don’t mind wasting your client’s money, then you could just build it ! If you’re like me, you’ll still end up frustrated from the fact that what you’re building is actually not being used, no matter how high the paycheck is.
  • You could try to convince your client that he will be better off not building this feature, because he doesn’t really need it. Depending on the person you have in front of you, it might be hard, but it can work.

The solution that I tend to prefer however is to go through an iterative process to build the system, starting with a Minimum Viable Product, and adding the rest of the functionalities as there is a real need for it, through an Agile process. This usually allows the client to find out by himself that he doesn’t need all the bells & whistles he had dreamt of.

Reinventing the wheel

If you really want to help your client out and reduce his costs, you might stand up and say: why don’t we integrate the work that I’m doing with the already existing project ? Or, since your work is obviously much better than the way the older project was done, what about integrating the older project within your work ? So you try to have the 2 sections talk to each other, and starts a long political discussions, with everyone being in favor of the integration, but no one really willing to actually DO IT. Way before this political discussion is over, you are done with your project and you move on, with the hope that integration will happen at a later point.

I still didn’t find a real solution to this one. One potential solution is to try to build software as services instead of closed blackboxes, so that if another section needs the same kind of service, they should at least more easily be able to reuse the service you built. That said, even if you build things as services, if there is no political push in the organization to make sections reuse the work of other sections and talk to each other, you will still be reinventing the wheel for a while.


I’m not saying you should never use the technologies mentioned above, even when doing simple projects, but when doing so, keep the following in mind:

  1. How much time are you spending on dev ops vs on the actual project ? If you spend more time on dev ops than on the project, you should probably give it a second thought.
  2. If some day you leave the project, how hard will it be for someone else to get up to speed ? How many things will the newcomer have to learn ? How many steps will be required to install the dev environment ?

For simple Drupal projects, I try to keep it as simple as possible: one single CSS file for the whole theme, based on Bootstrap and Fontawesome, and as less modules as possible to keep things simple: no Grunt, no SASS, no Compass… Docker or Vagrant can still be used if wanted, but the site can still be run without it.

There are, of course, many more issues that can be encountered when building web projects, but those are, for me, the 3 top ones. To try to avoid them, keep it simple and try to understand as much as possible your client’s real needs.

Originally published at on December 2, 2015.



Développeur web et passionné de finances personnelles

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store