As a developer who has spent 10+ years working on Drupal sites, I often ask myself - is Drupal always the right choice? Drupal is easy to adopt into any sort of content management or user contribution site. However, there are times when Drupal isn't the right fit. This might come as a surprise to some as I write about Drupal a lot, but I want to highlight the questions you should be asked when embarking on a new project.
Single page site
Creating a Drupal site for a few pages of static content is overkill. Hosting a Drupal site requires a paid web server, provisioned with the required software. That cost doesn't take into account the support needed for the server or updates to the Drupal site.
The fact you can set up a static site using free hosting on a variety of different platforms means that hosting such sites is very accessible. The initial creation of the site template itself might take some work, but once it's done it can be hosted pretty much for free and won't need to be patched to cover security updates. Take a look at platforms like Netlify or Github pages for more information.
This is also a great choice if you are just getting started and need a holding page whilst your main site is being built.
Blog
I have built a few sites in WordPress, and if there is once thing that WordPress excels at it's being a blog. If your requirements are basically a blog and a few other pages then WordPress might be a good solution. You can also host your WordPress site on wordpress.com to take away the hassle of updates and other requirements.
I have seen people create full shopping experiences around WordPress, but at this point, WordPress is just serving the page as most of the work is done using custom code. The WordPress administration screens also tend to get a little cumbersome when you install lots of plugins so keeping that to what you need is a must.
If you have further plans for expansion into custom content types or commerce then Drupal is a good choice as it will allow you to expand and adapt in the future. Drupal's default blog isn't too bad, but in a couple of hours, you can create a blog content type and listing pages on a Drupal site.
Shop
The usual route when building a commerce system in Drupal is to use the Drupal Commerce suite of modules. By doing so you can create a product display system and checkout process directly into the site. So your content editors can use the tools available on the Drupal site to create content that sells.
That being said, there is a choice to be made here. When you build a commerce platform in Drupal there are things you need that you might not immediately think of. You can set up product pages and checkout processes easily, but don't forget the administration. Consider manual changing of order states, fulfilling orders, or looking at weekly totals. Things that are needed in the functionality you build.
Where Drupal excels with commerce is in creating a customised checkout process. For example, if you want users to enter the checkout process, fill in custom fields and branch the checkout process depending on what they entered, Drupal is great at this. The Drupal Commerce checkout process has plugins and configurations you can set up depending on factors like what the user has in their cart.
If you're looking for a fully featured commerce site without a need to branch your checkout process, look at Magento. This is a mature commerce platform that has lots of great features and community support. Also, Magento can be installed side-by-side with Drupal to provide a powerful content system and a fully-featured commerce system.
Alternatively, look at SaaS solutions like Shopify. Start a commerce website with administration tools to help you manage the shop.
How much will I need to fight against Drupal?
You can go a long way towards a fully featured experience without writing any code in Drupal. The hook and plug-in systems allow you to customise that experience. Including different content types and options. Drupal's fieldable entities system allows you to attach any kind of data to any kind of entity. So, building up your data structures and creating searchable lists is easy.
The problem comes if you want to change things too much. The more hooks you add change how Drupal and third-party modules work, the more difficult it will be to update those sites later. Additionally, unless you're familiar with Drupal you might end up fighting how it wants to do things without your own code.
As an example, I once built a site that contained a large and complex form that spanned across multiple pages; even having parts where the user would click a link in an email and come back to the form. When looking through the specification for the site I realised if I used Drupal I would spend time trying to stop it from doing its own thing with the form. There was no need for the CMS or user management part of Drupal, so I'd also spend time hiding and restricting the use of them. I took the decision to not use Drupal and built the site using the Symfony framework as a starting point. This was the right decision. We rapidly progressed through the development of the form. We even had time to incorporate the extra functionality requested by the client.
How large will the site get?
An important consideration in any project is how much traffic it will receive. However, this isn't just about the amount of traffic. More, it's about the amount of functionality the site is expected to have. Most experienced Drupal developers know you can keep adding functionality to a Drupal site and it will chug along. There will come a point where adding functionality will have unforeseen consequences that you need to be careful about.
Drupal's hook system, whilst powerful, can lead to action at a distance anti-pattern. This is where code in unrelated modules will affect things you are working on. For example, you might have a site that will implement a load hook to alter the data contained in a page as it is fetched from the database. There is nothing to prevent the addition of another load hook that alters the data on the page in a different way. This might sound like an edge case, but I've seen sites where multiple implementations of the same hooks can lead to them fighting over the same data.
Split it!
One good solution to this is to distribute your Drupal site into separate instances. Drupal is good at being split into separate sites. This is thanks to the multiple single sign-on technologies that are available as third-party modules. It's possible to split your news section into a separate Drupal site so it can be worked on independently; without affecting the main site. This also means that the codebase for each subsite can be simplified as it only needs to contain the relevant modules.
There is the issue of deployments as well. If your Drupal site is so large you need to take it down for an hour to deploy it, you should consider splitting parts out. I would also suggest taking a look at your deployment processes as well. I've deployed multiple large sites in a multi-site environment without more than a few seconds of the Drupal maintenance page.
There is a point where the site is so large (say, Facebook-large) that Drupal would be a small part of a larger picture. Facebook is built on PHP (the same technology Drupal uses. However, the scale of engineering at Facebook is entirely different. They had the resources to create their own PHP dialect (called Hack) to get more speed out of PHP itself.
Is Drupal always the right choice?
As much as I like working with Drupal, I don't think it should be used in every situation. Most Drupal developers I've spoken to have a lower limit on sites they would use Drupal for. Generally, a single-page website doesn't need more complexity than a CSS compiler.
When you override lots of things Drupal does with custom code you struggle to keep the site working. I know from experience applying updates to modules that are heavily overridden is fraught with difficulty. So, I keep a careful balance between adding new functionality and overriding the existing features. Though, having an external testing suite like Nightwatch or Behat can go a long way. They help solve any doubts that the updates you're applying will work.
Out of the box, Drupal gives you a battle-tested authentication and permission system, with a powerful content management system. But knowing how to work with Drupal, rather than against it, is part of what makes a good Drupal developer.
So, is Drupal always the right choice? The answer is, no, not always!