Can You Launch A Tech Startup Using Drupal?

Submitted by graham on

Yes you can.

In that case, should you launch a tech startup using Drupal?

Maybe.

This article will equip you with the information you need to make a sound assessment of whether you should choose Drupal for your startup company whether you are a non technical founder, an experienced CTO or a technologist looking to step up into an executive role.

Drupal, or any other piece of open source software, can provide you with an incredible platform to scale your startup from nothing more than a set of requirements to a profitable company in a highly time and cost efficient manner.

But Drupal is not a silver bullet for cash strapped tech startups looking to launch their MVP on the cheap. I have been contacted by several CEOs who share a similar tale of woe: “we used an intern/freelancer/agency to build our MVP using Drupal and it is horrific/broken/not fit for purpose. What can we do now?”.

It is fair to ask, “If Drupal is so good then how can it result in such poor outcomes?”. In my experience there tend to be two main possibilities:

  1. Drupal was never going to be the right tool for a particular job and the project scoping was not rigorous enough to identify this.

    Abraham Maslow said “To the man who only has a hammer, everything he encounters begins to look like a nail.”. The lesson we must learn is to make sure you have more than one tool in your toolkit before choosing which one is best suited to the job at hand, since choosing from only one option is really no choice at all.

  2. The implementation was not executed by somebody proficient in using Drupal to model the business needs of a particular startup.

    Every business has different needs and differing needs can be met by differently skilled development teams. Let us consider a business to be a patient and the development team to be a surgeon. Would a patient requiring heart surgery visit a dental surgeon to perform their procedure? Certainly not. So why would a business requiring a highly scalable, data driven, transactional web application instruct a development team proficient in building static brochure websites? It certainly won’t work out cheaper in the long run.

Given the polar extreme outcome possibilities, you need to answer some key questions to steer clear of disaster.

  1. Can the Drupal feature set be configured to solve a large proportion of the problem that our company is aiming to solve?

  2. Is the Drupal architecture compatible with how you must interact with your users?

  3. Do you have access to somebody who you know can convert your business needs into a scalable Drupal configuration?

Can the Drupal feature set be configured to solve a large proportion of the problem that our company is aiming to solve?

Drupal is most likely to be a good fit for startups that require functionality that is baked into the core Drupal code base. For instance:

  • Users - do you need users to register, provide personal information, login to an account and allow admin to manage those users?

  • Content - do you need to create, manage and publish content?

  • Data - do you need a user interface for managing data that will be stored in a database?

  • SEO  - do you need the tools to support an SEO campaign based on your content?

  • Blog - will you be writing a blog to keep publishing fresh content?

  • Flexible data types - do you need to create new data structures over time, such as Article, Subscription, Person, Order, Transaction, Ticket, Story etc

  • Multilingual - will you be publishing content in multiple languages?

  • Community - will you be building a community of users who comment on each others blog posts?

  • Presentation - do you need flexibility to easily customise templates or run multiple instances of a website each using a different theme (a set of templates and styles).

If your startup is not dependent on at least some of the items in that list then the chances are that Drupal is not the best tool for the job in your case and you should invest time looking for a better alternative.

Is the Drupal architecture compatible with how you must interact with your users?

Would it be sensible to build Facebook using Drupal? Absolutely not.

We only need to look at the data Facebook handles. Every single second Facebook generates an awful lot of data. Each interaction involves small amounts of data that must be stored extremely quickly. Drupal tends to have quite heavy database operations even when only small amounts of data are changing. This will present a barrier to scaling up since you will have to work very hard to store the data as quickly as it is being created, which is likely to result in performance problems.

Being largely a single page app there is not the opportunity to benefit from Drupal’s strengths such as managing pages of content and supporting SEO. The live updates that appear in a user’s feed also require very lightweight database reads, whereas Drupal tends to have data spread across multiple database tables making it slower to access. At a minimum much of Drupal’s core functionality would have to bypassed with custom functionality to deliver anything near scalable in this use case.

What we are seeing is that to deliver the required functionality we must exclude many of the features that would typically make Drupal a compelling choice. There is a cost/benefit tradeoff when selecting a development framework. The costs result from compatibility imperfections that you must solve due to the framework not being designed specifically for your use case. The benefits come from not having to reinvent the wheel for all of the components you require that the framework can offer you out of the box.

A decision maker ought to include cost/benefit analysis in their framework selection process and when a framework asks you to sacrifice benefits without lowering costs then we are receiving a clear signal that we must start evaluating other options.

Would it be sensible to build Tripadvisor using Drupal? Quite possibly

Tripadvisor features many components that exist as core Drupal functionality:

  • User account creation

  • Multiple content types: hotels, flights, restaurants

  • Users can leave comments on pieces of content

  • The site uses a page based site structure with traditional menu navigation and search

  • Pages are comprised of several reusable content blocks

  • SEO is a key requirement

  • There are community features such as a forum

It is clear that there are several areas where we do not need to reinvent the wheel by basing a Tripadvisor build on Drupal. In terms of the cost/benefit analysis concept that we introduced earlier we are scoring well on the benefit side of the equation.

On the cost side of the equation the most significant question marks for this type of project will include:

  • Can we scale it effectively? Drupal is extremely flexible but that can come at the expense of a significantly heavier page load process when compared to a bespoke built solution. This tends to dictate that a caching strategy is required and in turn this forces us to consider how fresh the data on our pages must be, since if a page is cached then by definition it could have been built some time ago and might lack fresh data. There are solutions to this, but they add to the costs we must consider.

  • Will caching be effective? When a website contains a huge volume of pages with a significant percentage of them being requested infrequently it is not always easy to efficiently maintain a cached version of all pages before they are requested. In aggregate this can mean that a significant percentage of users experience poor page load times due to the content they are requesting not having been cached recently.

  • Once we get beyond the features that Drupal provides out of the box, will its architecture hinder the development of other must have features that you cannot compromise on? For example, if you require data entry forms that save as you work, similar to Google Docs, you will find that Drupal is not set up that way and you will need to consider workarounds that bring additional costs.

In this example we can see that Drupal might very well be a sensible choice for the project. However, it is important to consider that this does not mean it will present a cash strapped CEO with low cost route to market where everything just works out of the box with a little bit of configuration. Rather it might present the CEO with a lower cost route to market when compared to alternatives once the skills available for the project have been assessed.

Do you have access to somebody who you know can convert your business needs into a scalable Drupal configuration?

If the answer to this question is “No”, then you have three options to choose from:

  1. Bring someone onboard who can convert your business needs into a scalable Drupal configuration - not just any Drupal configuration, a scalable one. But since you are not already endowed with Drupal skills, first verify that you get enough benefit from selecting Drupal to warrant the cost of this.

  2. Consider a different platform if you have access to alternative expert skills.

  3. Take a big gamble. First gamble that Drupal is the right option for you and then gamble on a novice and hope their lower rate offsets the investment in upskilling them and the extra time spent undoing mistakes due to learning on the job.

If you do have access to somebody who can convert your business needs into a scalable Drupal configuration, how should you proceed if we theorise that there is definitely an alternative tech stack out there that we determine in some way is definitely a “better” tech stack for the project than Drupal? Should you choose the better alternative?

Not necessarily.

There is a very strong case for favouring a set of tools over which you have mastery rather than a set tools, perhaps newer and more exciting tools, that you speculate might be better in some way. The risk with the newer, less familiar tools is that your lack of familiarity might lead to suboptimal decision making that will ultimately block your progress, burn your cash and kill your startup.

If you believe there is a chance that an unknown technology stack might be the best stack to use then evaluate it thoroughly before sinking your development budget into it. Being slightly better is not good enough, you ought only consider unfamiliar alternatives that are so much better that the potential gain outweighs the risk of the unknown, the cost of upskilling and the additional time required to get to market. An expert will be worth their weight in gold if they steer your clear of fundamental architectural pitfalls that prevent scaling your startup.

Consider how certain you are that your requirements today will be your requirements in 3 months, 6 months, 1 year etc. The greater the probability that you might pivot from your current plan, the less value your initial build might have and therefore the less return you might earn on your recruitment/upskilling investment.

If you have access to a Drupal expert that can build scalable web applications you might be able to bring a product to market more quickly and cost effectively with most of your desired feature set. This will allow you to learn what your customers want more quickly, which might cause you to pivot or alter your requirements more quickly in which case you might find that your choice of technology stack needs reevaluating, so the less you have invested in it the better.

What’s next?

Now it is time to pick your tech stack. Will it be Drupal, will it be open source, will it be a bespoke build?

Still not sure? Get in touch, tell us what you are wrestling with and maybe we can add some more information to help you make the next step.