by David Snopek on June 25, 2015 - 1:45pm

I've been doing a lot of soul searching over the last year, trying to figure out what my next business move would be. I think I'm finally ready to move on from my last startup, and I definitely want to get out of selling hours of my time as a consultant (it was always meant to be temporary - I really can't believe I've been freelancing for 5 years now).

Around DrupalCon Austin last year, I decided that I wanted to not just build something with Drupal (like my previous couple startups), but to build something for Drupal.

But what?

What critical piece is missing from the current Drupal commercial eco-system, that if filled, would not only generate a profit for me, but ALSO accelerate Drupal adoption and make Drupal users kick more ass?

I finally have an idea that I'm excited about!

Read the full article to find out what it is...

Hint: It's not a hosting platform ;-)

Lately, there seems to have been an explosion of really cool new hosting platforms added to the Drupal eco-system, for example: Pantheon, Platform.sh, Omega8.cc and Acquia's ever evolving offering.

I think if we were to go back 3-4 years, the answer to my question ("What does the Drupal eco-system really need?") the answer would, in fact, be better Drupal-specific hosting options.

But today in 2015, we've got some really great options!

Certainly, there's still room for even more new hosting startups to do cool things, that haven't been done yet. But the existing options have already pushed Drupal forward, and adding something new would be more of an incremental improvement rather than a giant leap.

What I'm looking for is a empty vacuum that needs to be filled.

I'm looking for what hosting for Drupal was 3-4 years ago.

What's preventing Drupal users from kicking ass?

If the goal is to help Drupal users reach their full potential and kick as much ass as possible, we've got to first ask:

What is preventing Drupal users from doing it today?

Here's what I think:

Chris wants to build a website selling cameras. He heard that Drupal is pretty cool, went to a DrupalCamp and even found a freelancer (Sara) who knows Drupal Commerce and will help him build his new site! After a month and around $5k paid to Sara (50hrs @ $100/hr), the site is live and Chris starts shipping cameras to customers.

A year passes and now Chris is doing pretty good business and depends on his Drupal site for a good portion of his income. But he needs a little help:

  • He's been getting e-mails about security updates for some time. He wants his site to be secure for his customers but doesn't really know what he's supposed to do.
  • He needs some changes made to the site that he thinks should simple, but doesn't quite know how to make them.
  • An important listing page on the site has started running really slowly and it's annoying potential customers. How can he make it faster?

He called Sara to ask for help, but she's booked up building new sites for other clients. He's tried to find another freelancer but they're ALL busy! There's some bigger Drupal shops who'd be willing to handle it, but they aren't willing to do such a small project (2-4 hours of work by their estimates) and want $150-$200/hr which would seem reasonable to Chris for building new functionality, but not simple maintanence stuff like this.

So, Chris goes to a Drupal meetup (his first event since the one DrupalCamp he went to) and he learned how to perform the security updates and make some of his changes. But there's a couple that he just can't figure out how to make. And by now he's spent 20 hours over a couple months banging his head on this.

"Can't someone just do this for me?!" Chris yells in frustration.

Then one of Chris' friends suggests that this might be easier with Wordpress or SquareSpace or (fill in the blank).

Good bye, Drupal!

Why we fail at support and maintenance

The Drupal commerce eco-system is primarily made up of full service Drupal shops and freelancers who focus on building new sites.

And, for the most part, they are awesome! They've helped build some of the biggest sites on the internet.

But we don't have nearly as many options for support and maintenance of existing sites.

Yes, most Drupal shops will be happy to sell their clients a continuing support contract to maintain the site after it's built. Some will even sell support contracts for sites that were built by others.

But from the perspective of a Drupal shop, your main business is building new sites for an hourly rate, so maintenance and support for a handful of old sites pulls developers away from the current project (which has a tight deadline!), and it probably doesn't pay enough to justify the developer hours spent.

So, it's annoying and doesn't really pay off, hence Drupal shops try to avoid it and tend to deliver sub-standard service when they do provide it.

Also, from the customers perspective, they want security updates and for small changes to be made for them, but they don't really want to pay high hourly rates for maintenance, even if they would for the initial creation of the site.

Beyond "full service"

Here is my idea for a startup that solves this problem:

A productized service, called myDropWizard, that provides support and maintenance for a customer's Drupal site, for a fixed monthly fee (rather than an hourly rate).

We'll take care of security updates, and performing basic, one-off maintenance tasks on request.

Unlike a Drupal shop who also does support and maintanance, this is ALL we would do.

Sound crazy?

From the perspective of a Drupal shop or freelancer, I could definitely see why you would think so. :-)

The key is that this isn't "full service", it's a "productized service."

That means:

  • The scope of what we provide will be carefully crafted and communicated to the customer. We don't build new functionality, just make certain kinds of changes and fixes to existing sites.
  • We can create defined processes and automated tools. Because the scope is limited, we aren't going to do anything and everything for the customer, but will do lots of the same kind of things over and over again. This can be systematized or automated, allowing for economies of scale.
  • Speaking of scale, most products (unlike "full service" offerings) only really work at scale, and this is no exception. In fact, this is such an important point I'm going to make a new section below to dig into it. :-)

But the main point here, is that a productized service is something that sits between a product and a service and can't really be thought of like you would a full service.

Like a service, its "done for you", whereas with a full on product, the client has to learn how to use the product and do it themselves. But like a product it's not "do absolutely anything" - you're delivering a specifically defined thing everytime.

Awesomeness done at scale!

The full promise of this idea really, really, REALLY depends on scale.

Providing this productized service to only 10 customers would probably lose money. You're spending more resources to do the security updates and fullfil customer requests than you're bringing in.

But at scale that turns around.

First of all, once you've done the work of evaluating this week's security updates and worked out any issues, repeating that for any number of sites (with the right tools) is no harder than doing it for one site.

It's the "one-off maintenance tasks on request" that's the sticky point. However, not every customer is going to make a request every month - it's probably a relatively dependable percentage. So, this works similar to health insurance: in any given month, the healthy pay for the sick.

So, while at 10 customers we'd lose money, at 100 customer we'd probably make a profit.

But at higher scale is where this really gets interesting!

Doing it for 1000 customers would probably make sizable enough of a profit and that it would essentially allow us to spend as much time as it took to handle a customer request, without having to count every minute to make sure our developers don't spend too much time on each request (within our defined scope, of course).

This is really what gets me excited: we could provide really unbelievably amazing support to our customers, at a level and price point that a Drupal shop never could!

Similar products outside of Drupal

This isn't a new or unique idea - it just hasn't been done in Drupal yet.

Wordpress has wpcurve.com, which is pretty much exactly like my idea. (What is it about "great artists stealing"? ;-))

And they actually publish monthly reports with their monthly revenue, number of customers, conversion rates and so on, so we can get a really cool peek into their business.

In their report for April (for some reason I'm getting a blank page when I go to the May report - hurray for Wordpress!), they state:

We reached 826 total customers with a slight decrease of 15 customers for the month. Our run rate of $66,154 USD has only grown moderately.

Of course, Wordpress and Drupal have different use-cases, customers and market sizes so the business model can't be 100% the same. But I think the level of success that wpcurve.com has enjoyed bodes well for doing something similar in Drupal, even though there's still a lot of really difficult and interesting problems to solve.

Is this idea brilliant? Or just totally crazy?

I don't know. :-) But I hope to find that out over the next few weeks and months.

I'm planning to talk with friends and acquaintances with businesses in the Drupal space to do a sanity check and get some new ideas. (And I'm actively looking for advisors and co-founders in case this is something you'd like to get involved in more directly.)

I'm also going to be interviewing potential customer and trying to validate that the idea and price point makes sense, and discover any other road blocks that I didn't think of which are preventing Drupal users from kicking ass.

Conference season is upon us and I'll be heading to DrupalCamp Twin Cities (this weekend, yay!), NYCCamp, DrupalCorn Camp and DrupalCamp Wisconsin. This will be a great opportunity to try and get feedback from people I don't already know.

Anyway, I'd love to hear what anyone and everyone thinks! Please leave a comment below!

Topics:

Want to read more articles like this?

myDropWizard.com blog Subscribe to the myDropWizard.com blog and recieve e-mail updates when new articles are published!

Add comment

o