Mobile First has become the best practice way to write a website since the book by Luke Wroblewski appeared in 2011. Yet, what I do is still the opposite - I start with the desktop - so, in the best interests of cynicism, I've called my approach Mobile Last. Let me explain why I use this approach.
The reasons for the Mobile First approach can be explained in simple terms. First, your website must work well on mobile, because more and more people use thier phones as their main way to browse websites - well on the way to becoming the majority. Second, mobile sites have to be kept simple, because the screen size is so much smaller. Third, download speeds on mobile are usually like dial-up once was or even worse, so that simple site design has to also be small.
So the result is that all the bells and whistles of a fancy desktop website will be much too slow to load (and, being big, also too expensive to load) on a phone - and what a waste if the fancy stuff is never going to be displayed anyway. So, according to the Mobile First approach, you should start with a very simple small mobile website, and use Progressive Enhancement to add features for the desktop version.
The problem with this approach is that there are only two ways to do progressive enhancement, and they both make life rather complicated when you're trying to cope with legacy browsers. And that's the problem that I have, because some of my sites have a demographic that does include plenty of people with older browsers (and equipment).
One way is to serve up different sites for different devices. This is a pain because you have to sniff the user agent first to figure out what the device is, and people can sometimes have it set wrong. Because it's an extra round trip and easily becomes out of date as new devices come on the market, this is now used less and less - and the website optimisation pages PageSpeed and YSlow don't like it either.
Media queries are the other solution, and are the usual way to implement Responsive Design, where there is only one version of a page, and it's rearranged for different sizes of screen. The problem is that old versions of Internet Explorer don't understand media queries, so with a mobile first design, they will try to display the mobile verion of the site. And so you have to add extra bits and pieces to detect Internet Explorer and make it behave correctly.
How Mobile Last works
The whole problem goes away with a Mobile Last approach using Responsive Design. If you can keep the content of the desktop site so simple that you want to have all of the same content on a phone - and that's the key question - then Mobile First isn't really needed.
Old versions of Internet Explorer are happy, because they can't understand the media queries that tell the web browser to be different on smaller screens. And there's no real need to allow for phones that don't understand media queries, because they are now too old and too little used for anybody much to be browsing the web on them.
Using CSS3 for the prettiness then works well, because older web browsers will again just ignore what they don't understand, so older Internet Explorer will just leave out rounded corners, shading, gradients and so on - so there's no need to have any separate design.
Media queries can then take care of the rest on phones - such as removing fancy backgrounds, collapsing the menu so that it doesn't take up most of the screen, and rearranging the columns to be stacked instead of adjacent on small screens.
Of course you can avoid all of this mess by just using a Mobile First framework such as Bootstrap. But because I don't, I can keep the number of files to be loaded very low, which improves loading speed (since web browsers typically only fetch 6 files at a time from a server). For example, on Sydney By Ferry, most web pages consist of only 5 files (and only 2 new files on subsequent page loads). By comparison, WebSiteOptimization says that the average web page had reached 112 files by July 2014.
And anyway, I figure that I learn a lot more by coding the HTML and CSS3 myself rather than having to spend my time understanding how somebody else has implemented it in their framework.