Few developers in the startup community would recommend making a product with Drupal. If you are building a web or e-commerce site, sure, but if you want to build a SaaS product there are plenty of technologies that are easier to productise. Installation profiles and features were added onto Drupal 7 as an afterthought, not as a central design principle and, as a result, have plenty of shortcomings. It looks like this will get better with Drupal 8 but, for now, by design, Drupal is not architected for easy redeployability.

Sounds pretty damning? It may be, but a lot of work has gone into remediating this problem, and Drupal is still better at redeployability than most other CMSs. CMSs are designed to be products themselves, not to be used to build products. Drupal however, is hyper-configurable. As a tool it is made for infinite extensibility, to keep as many options as open as possible. Compared to other CMSs, it’s easier to extend even if you don’t yet know what you will want to do in the future – which makes it great for one-off tailor-made projects. And this is a strength for some types of products and for certain parts of the development cycle.

In our consultancy, we started building “products” with Drupal because it was the right thing to do: all our products had some technically challenging component that we could contribute back to the community. Our developers were able to grow their skills significantly through the challenges they overcame and get an opportunity to build their reputation in the community. But these initial products didn’t make much business sense, except maybe as cost-leaders to promote our services. Most were not really sustainable as standalone products.

It has taken a long time, but after many iterations, we’ve learned a lot from these experiments. The projects we launched in the past two years have been much more successful. We still need to keep on fighting to get through what Seth Godin calls “the dip,” but we’ve gained a key insight; we now know the types of products we should be using Drupal for. In this article I want to share with you the most important of these insights.

In his book, The Dip, Seth Godin argues that anything worthwhile requires you to go through “the dip,” a moment when you have to struggle with all your might to succeed. Most people give up in the dip, right when they should push hardest. The dip is what keeps services and products valuable; without it, they become commodities.

Drupal as a Prototype

Creativity requires boundaries. When you can do anything you want, it is really hard to be creative, because you get paralyzed by choice or, worse, you try to build everything perfectly the first time. It is now generally accepted in the startup world that the only good way to build a product is through an iterative, lean process, in which you create as many learning points as you can, using Minimal Viable Products and customer development to shape a product people actually want.

I’ve found Drupal to be an amazing tool for prototyping: content types, configurable fields, rules, triggers, profiles and a whole string of contributed modules make it really easy to throw together something fast. In a few hours of clicking you can go from an idea to a product your customers can interact with.

For example, the last week of January I built a first prototype for LinkForward, a web application that makes it easy to ask for introductions. The first iteration took me four hours. It had a user profile, actions that send e-mail introductions, a view that shows a single profile at a time – to reduce cognitive load – and a system of flags to keep track of the things you’ve already checked. The second prototype after four more hours of work, allowed users to follow each other, so that they could prioritize asks from their acquaintances. After only 12 hours of development work, I was inviting people from my network to check it out.

As a result, I believe that Drupal is a really great tool for building what Alberto Savoia calls pretotypes: first prototypes of services that might fake most of the functionality a full prototype would require. It enables a focus on the user interaction, to discover if people will actually use a product, not just say they want to use it.

Minimal Viable Product (MVP) is a term coined by Frank Robinson, and popularized by Steve Blank and Eric Ries. It “describes a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.

A pretotype, as defined by Alberto Savoia, is very similar to the concept of an MVP, but is more specific: it focuses on “making sure that you are building the right it before you build it”. The weakness of MVP as a concept is that it’s too broadly used. Sure, it’s easy to say that a prototype will not be viable without a certain feature (e.g., design, a mobile app, LinkedIn integration, etc.), but pretotyping helps founders create something barbarically minimalistic.

Great! It’s easy to build a pretotype that helps you make sure you are building the right “it,” and it’s especially suited for startups, where the majority of the innovation is in the business model, not in technical development.

But... Be careful you don’t overdo the feature side. (A tool that limits the modules you can use, like Drupal Gardens can be a great box to think in.)

And don’t expect to keep all the work you’ve done; it’s important to learn and rebuild from scratch.

Drupal for Non Technical Founders

Drupal is an amazing tool for non-technical founders because there are so many options to create truly complex behavior – without writing a single line of code.

Actions, triggers, and rules let you create events that your product will respond to. A developer in Belgium told me about an enterprise company where a product owner creates prototypes of products in Drupal, before his developers build it out in Django. I don’t know why his team doesn’t use Drupal, maybe because they like Python better than PHP. Whatever the case, it is a fascinating example of the power of Drupal for non-technical entre/intrapreneurs.

And that’s the reason that I fell in love with Drupal, back in 2006. My first website was a technology listing page for a biotech research center that I quickly “clicked together” in Drupal. In all the years that I’ve been leading a Drupal company, I never needed to learn to code to be able to architect or even build projects. I’m grateful for Drupal, it gave me superpowers on the Internet and allowed me to build the foundations of some really complex systems.

Great! You don’t need to be a developer to build a prototype; Drupal allows you to build complex websites without a single line of code.

But... If you are not familiar with Drupal, you might make architectural decisions that cause problems down the road.

Drupal as a Platform

Most people start using Drupal because it’s such an amazing platform:

• if you build a Drupal product, there are a range of modules that can be used to extend your product. A vibrant community works on thousands of contributed modules that provide a large range of functionality.
• Drupal has a whole ecosystem of consultancy companies, hosting and support solutions, and a plethora of integrations with third party services. As a result, it is much easier to build a whole product.
• Drupal has a track record of large enterprise scale projects at some of the most prestigious organizations. When you sell a Drupal product, you are selling a pre-configured instance of Drupal. This makes it much easier to answer questions about security and scalability than with a product that you have developed from scratch.

All of these reasons make Drupal terrific for "me too” products. As a startup, you can step into an already proven market niche with an open source version of a software solution. You can use your product as an open source cost-leader to gain market share in the enterprise service market. Acquia’s OpenSaaS program is built around that concept: to work together with teams in the community who have developed a Drupal version of a certain product category, that you can sell with your sales force.

“Cost leadership” is a term that was developed by Michael Porter. It describes a business strategy in which a company becomes the leader in a market through a focus on cost control. In the open source market, with a free product, the product itself has – by definition – the cheapest purchase cost. When you give away a free product as a commercial entity, you need to derive value from complimentary services. Ideally, these provide a subscription-style component that generates recurring revenue. The most economically successful open source software products use a razorblade business model. They give away their product and recoup their investment on hosting, support, and other complimentary services. (“Razorblade model” refers to the shaving industry, where handheld razors, like Schick, for example, are sold at a low price, but are only compatible with replaceable Schick blades.)

NuCivic’s DKAN is a tool that helps organizations publish open data sets. Through the OpenSaaS program, they were able to leverage Drupal’s reputation and familiarity to rapidly gain market share in the Open Data solutions market.

Another example of a product that leverages Drupal as a platform is, of course, Drupal Commerce – The Commerce Guys’ distribution that packages the functionality you need to make e-commerce sites. The Commerce Guys monetize their development through a combination of application support, professional services and development, and production hosting; in most cases, they leave the actual development of individual projects to their network of partners.

Phase2 created OpenPublic as a platform on which they can build websites for government and public policy organizations. In contrast with the Commerce Guys’ partner strategy, Phase2 actively seeks to implement projects themselves. Even when they share OpenPublic with the community, it gives them a marketing advantage when companies in the public sector go looking for a Drupal partner.

Great! Drupal is a mature platform that makes it easier to create a whole product.

But... As a Drupal consulting company it’s easy to start building “a product” without properly validating the opportunity for generating sufficient revenue from add-on services.

Drupal as a Frontend

Recently we were asked to help a Silicon Valley bio-informatics startup with the development of the frontend for their web platform. They were developing their API backend in .Net and wanted to use Drupal as frontend for their customers. At first we were surprised that they wanted to use Drupal in this way, and that they didn’t choose to build a frontend application in Angular or another Javascript library. Their choice made a lot more sense once it turned out that the frontend also needed to handle the e-commerce component of their application.

Other products have been built this way: Apigee’s developer portal is built on Drupal and lets you create API documentation. It also supports blogging and provides threaded forums. The main advantage of using Drupal as a frontend for their services is that their customers can customize the developer portal to meet their specific requirements.

Great! Plenty of developers know how to customize Drupal; that makes it easier to customize the interface for your services.

But... The theming system in Drupal has its quirks.

Drupal as a Market

Drupal has a worldwide community that is very well interconnected. It is easily addressable through community events, like Planet Drupal and other community communication channels. Two years ago, we completed a successful crowdfunding campaign in the Drupal community for WalkHub, a Drupal product that lets you record Walkthrough tutorials on top of web applications and websites. Targeting your product at the Drupal market however is not for the faint hearted. Drupal is a micro-market; it’s a great beach-head to cross the chasm to a mainstream market adoption.

Typical examples of productised services targeted at the Drupal market are, of course, Pantheon’s and Acquia’s hosting solutions.

Great! The Drupal community has a lot of early adopters and technical innovations that welcome anybody who wants to extend the capabilities of Drupal. This makes it easy to get feedback on your product.

But... Over a million reported Drupal sites might sound like a big market, but it really isn’t. In time, to be successful a product will need to expand beyond the Drupal community or use an aggressive sales and premium pricing strategy to generate sufficient revenue for significant growth.

Conclusion

I hope I’ve convinced you that there are significant opportunities for building products with Drupal. Even if you are not yet a Drupal geek, I believe it can be a valid strategic choice.

Image: © by Ondine Corewign