How you build a Drupal site will greatly depend on your personal preference or the preference of your boss/client.

A favourite debate between other developers and myself is if it's better to:

1. start with a pre-made theme and then fight it to remove all of the things you don't want it to do, or
2. start from scratch and build things you might have built several times in the past

I know what you're thinking, start with a simple 'base' and then add the extras. However, with years of experience, that never seems to quite work the way you think it will. The base theme always seems too basic, so you end up taking a pre-built site based on the base model, and then modifying it. Several sites later and you never return to the original base theme, and each site you create becomes a mix of others. In the end, you either end up with sites looking very similar or each site starts with a mess of things you you never use....

My favourite way to build a theme, especially if working with web/graphic designers who don't like too much restriction, (trust me, I've tried explaining the 16 column grid layout and seen the life drain from their faces). Is to 'Drupalise' a flat theme.

So what do I mean by that? Ok, so here's how it goes:

1. The web/graphic designer designs the visuals and sends to the client to get it approved.
2. The client approves it or returns to step 1 and repeats.... (many times probably but best to get it clamped down now)
3. The design is given to a frontend web developer who turns the design into a flat page, or set of pages.
   Now it's this step that gets interesting. The idea here is that the frontend developer can use whatever slider/megamenu/whizzy/bang/pop widgets and libraries they deem best for the task, without any restriction from the CMS.
   So far, the results I've seen have been really clean markup, with a small handful of JS/CSS files.
   If the developer has basic PHP knowledge then they can even separate out the header/footer/nav sections and use the include() functionality to pull them into the flat page, which starts to help the backend developer when 'Drupalising' the flat theme later on.
   They also complete all the responsive/browser compatibility styling here too, so this can be seen and perfected at this stage.
4. The flat site can be uploaded to a server and shown to the client. This can be handy as some people need to see and click things rather than just look at a flat design.
5. The client (or designer) can sign off the flat site, request more inner templates be created, or request tweaks, again, easier to do here, than when loaded into the CMS.
6. Finally, it comes to me, to 'Drupalise' and turn into a working site.

I'm not going to provide a step-by-step description of how this next bit is done, as it'll greatly depend on the site and the design, however the basic concept goes like this... I start to look at Drupal as a basic 'in and out' system, where the CMS is used to input data grouped into content types, taxonomy/terms, etc, and the output is handled by the usual page/node/field templates along with views and view templates. The task is to get Drupal to replicate the HTML markup provided in the flat site. As long as you can add the same classes, id's and structure as the flat site, then styling and jQuery bits and bobs will work without a problem. If you get it right, the styling and functionality will work, and it'll be obvious if you're missing something. The trick here is often to remove HTML markup you don't need and place classes in the right places.

For me, this normally starts by looking at the design for an inner page rather than the front/home page, which tends to be much simpler than a home page and will become the template for Drupals 'Basic Page' content type. It's worth noting that the 'front' page can have it's own template anyway page--front.tpl.php for D7 or page--front.html.twig for D8/9.

I'll start by creating a theme and the .info file will contain a few obvious regions (the rest can be created as I build) as well as the CSS and JS files from the flat design. Then I'll look at the templates that build the main HTML structure of a Drupal page, html.tpl.php, page.tpl.php, node.tpl.php, etc. 

The beauty with this process is that the amount of modules you need is quite minimal (as you're not using lots of modules to build the page whizzy bits) plus the amount of JavaScript and CSS files are quite minimal. For example, you're not loading one carousel library for an image slider, another for testimonials, another for Tweets, etc. All of the Drupal caching still happens as your JS and CSS files are still added the 'Drupal way', you just need to make sure you don't include another copy of jQuery core, make sure the version of jQuery is the same (or similar using jQuery Migrate) and make sure your jQuery libraries are referenced after jQuery has loaded.

From a business perspective, this works really well:

• the designer can do what they want with a little restriction as possible,
• the frontend web developer can focus on styling, browser compatibility, responsiveness and functionality with the libraries and techniques they've used in the past without having to worry about 'what comes with the CMS', or any restrictions from templates... they just make the magic happen without even having to know what CMS is being used.... 
• the backend developer gets a fully working site and can 'Drupalise' it without having to worry about responsive styling, cross browser issues, etc. They can just focus on the nuts and bolts of the build.
• if the backend developer adds the content types early on, (the different types required with the correct fields needed) then another member of the team can start adding the content early on too, as they're just adding text into fields, uploading images etc., and the display will take care of itself as the theme builds....
• if the content goes in early then oddities (not thought of at the design stage) will crop up earlier and can be fixed earlier going back to the designer.
• if styling needs to be amended because of the last point, then the frontend developer can go back to their flat site build, add the fix and supply new stylesheets. The backend developer simply replaces the old stylesheet with the new one.

So each person involved gets to focus on his/her speciality without being restricted by the constraints of another. Well, that's the theory, that's how I prefer to build a Drupal site and I've had some pretty good results so far in D7, D8 and now D9.

In fact, my first D9 site was:

• built before D9 was officially released,
• originally supplied as Wordpress theme,
• I flattened it and stripped out the truly awful markup mess that had been created,
• then Drupalised it into a custom theme, and
• I didn't really have to worry about which modules had been ported from D8 as I was mainly using the core modules (Views is core) and template files
• my learning curve (from D7 to D9) wasn't too crazy as I was focusing on templates and not much mechanics

All in all, a successful project.

If you have any questions or comments, let me know, and if you have a better method, I'd be interested to hear it ;-)