Sergio Carracedo 
There is a great debate about which solutions to use when adapting a website for mobile. Usually, using CSS (style sheets) as a solution helps us create different visualizations across various mobile devices, but not all manufacturers follow the standards. The result on some of them can be unpredictable.
There is a wide variety of mobile types. On some, only the most essential graphic elements can be displayed, like websites from the beginning of the decade. On others, such as smartphones, web content can be shown better and even have more functions, run jQuery Mobile, etc. Although some of them, for example iPhone, do not work, nor will they ever work with Flash technology. To get the most out of a website, we propose two options:
A) Create a website that works on most mobile devices
We can make our site work on almost all mobile devices by cutting back on services and options, making a looser layout, without margins, etc. This way, we ensure that our website will adjust to the size of our iPhone, Android, or iPad, etc. On the other hand, when browsing from a desktop computer, our website may seem extremely minimalist, lacking options, and simple. Even if it is well-designed graphically, it may appear poorly organized. The user will find it difficult to navigate and understand what they are seeing, leading to frustration and a negative image of the site. Furthermore, when it comes to developing such a compatible site, it adds costs that often make it more worthwhile to create another independent site for mobile. We have encountered this problem many times when trying to make things work well in desktop browsers like Microsoft Explorer. It is better to create an exclusive CSS for it than to limit the options of others like Safari, Firefox, or Chrome.
B) Create a specific mobile site, parallel to our website
This way, we will have the certainty that our site will work perfectly, both on the desktop and the mobile device. We can simplify navigation, change the structure, and better organize the content shown on the mobile. We can also develop simpler code. Ultimately, the result will be more predictable, and we will have better control over bugs. As with everything in life, there is a good side and a bad side. In this case, the downside is that it will require maintaining two sites instead of one. At first glance, it doesn’t seem like much, but you will surely change your mind with projects of considerable size and multiple languages. If not well-controlled, we may encounter update problems between the contents of the two sites. It may also force us to sacrifice certain features provided by high-end devices for fear that they won’t work on low-end ones. You can’t have everything. In short, the decision of which method to follow will depend on the users the site is aimed at. If our audience has purchasing power, they will have high-end mobiles and we can offer them the maximum in web features. Conversely, if the purchasing power is low, the mobiles will obviously be low-end and we will have to think about cutting possibilities so that the application runs perfectly on all of them and thus reaches the widest possible audience.