Why Drupal is a great fit for startups

Another sales call today, with a prospective start-upper who thought Drupal might lower his costs to get a web startup launched.

And I didn't really answer the question directly -- because in the long run, if you're building something successful, you're going to spend as much on your Drupal site as you would building from scratch.

The key difference? How quickly you can get something in front of users that might help you get some traction and build your business.

The Starting Point

You have to start somewhere. If you build your entire stack, you'll never get anything useful launched -- at least not before a competitor eats your lunch. Twitter started with Rails. Facebook started with PHP. Lots of companies have started with lots of different technologies, and in the end, it's not the technology that makes the difference.

It's the users. It's all about making something that attracts a base of users, and makes them excited to come back. All technology has strengths and drawbacks -- once you're out of the gate, these become areas for improvements, not necessarily business-threatening roadblocks (unless you aren't paying attention!)

What Drupal gives you out of the box is a really great starting point. A fantastic administrative interface. A system for implementing content types, entities, fields, relationships, roles, permissions, groups, commerce, comments, and much much more -- practically out of the box. A big challenge with Drupal is not exposing too much too quickly, ending up in an unusable, confusing user experience.

Start with User Stories

So to make a successful Drupal-based start-up, you have to start with user stories. You need to identify who your users are, what different roles people have on your site, what their goals are, and what the user experience is to complete those goals.

You should do this regardless of your chosen technology! You should also do this before you do your design. First figure out who your site is for and what user experience you would like them to have. Then figure out what tools and technologies you can bring to bear to deliver that, then get a prototype up and running. Identify the information each user needs to be able to see, to accomplish their goals. Then, bring in a designer to make an experience that represents your brand and supports users accomplishing the goals you want them to do on the site.

A question of philosophy

Many startups begin with a very minimalist approach: implement just the bare minimum core functionality and put in nothing else. Only after you have a base of users do you consider extending and enhancing your platform.

This can work very, very well with Google and Twitter being prime examples.

On the other hand, if you're starting with Drupal, you have a lot of functionality you can deploy very quickly, which means you don't need to spend time writing yet another password reset system, or a shopping cart, or a rating system, or a user profile system, or a comment system. You simply turn these on and configure where to make them appear.

Where people seem to slip up with all this functionality is taking a step back and looking at what they've built from their users' point of view.

The nature of actually putting the pieces together in Drupal is substantially different from building a web application from scratch. When you're building from scratch, you can certainly find code libraries to speed your development and leverage frameworks to make it go faster. But you spend a lot more time coding from scratch.

With Drupal, you spend far more time evaluating other people's code than writing code from scratch. At least if you're doing it right. If you're doing it wrong, you're writing a bunch of new code that has nothing to do with Drupal...

The key thing you get by using other people's code is leverage. You can get far more done much more quickly, assuming you're selecting good quality stuff to begin with. That's part of the reason outsourcing Drupal development is so hard -- it's very difficult to tell from the outside whether the people you're hiring are using the best of what's available, or re-inventing wheels and forgetting to put in a rim to hold the tires.

Where does the money go?

Very little of what we get paid goes into writing code. It goes into planning, testing, debugging, tweaking themes to make things look good on mobile devices, refining forms, making user stories, diagnosing why something doesn't work the way it should, and more.

There is plenty of code already written in the world. While we love to write new code, we do our best to be smart about when to write it, and not create our own version of something that already works perfectly well. Our job is to put these best of breed components together in a way that supports the goals of the users.

This is exactly why the "develop offshore" model doesn't work anywhere near as well as inexperienced people think. The code is already written, it's all the high value work of understanding your customers and translating those into a working, runnable system using components that already exist that is the bulk of what needs to be done.

Drupal and DevOps

The launch of a web application is one day in its entire lifecycle. An important one, no doubt -- but it's like buying a building for your store -- while the location, paint color, and layout has a definite impact on its success, that's hardly the most critical thing to making your store succeed. It's the day-in, day-out operations that count. Maintenance is important. Security is important. Merchandizing and inventory control is important. Having tools and space for your employees to do their jobs is important. The actual store building? Not so much! It's important, yes, but any building will do if the rest of those elements are in place.

What we love about Drupal is how it's built to change. You can start with a very small core functionality and plug in the next user story when you have staff ready to make that a great user experience for your customer. You own the site, you're not dependent on a "software as a service" vendor to make changes (or possibly vulnerable to them taking away something you rely on). You can get something up for your users very quickly and relatively inexpensively compared to building from a less complete framework -- but if you skimp on the experience, your users will notice and may not stick around for long.

DevOps is a movement within Information Technology that removes the divide between Development and Operations -- both are aspects of the same thing. Instead of having developers create something in isolation and throw it over the wall to Operations, who may not fully understand what was built or how to improve it later, with DevOps the same people build and maintain the system.

That's what we do here at Freelock. We start with Operations -- let's make sure your site is safe, secure, and handling its currrent needs, and then let's discuss how to improve it. Drupal is a fantastic platform for supporting this type of ongoing work.

The next challenge we find among our customers is reclassfying the work, and budget, from a capital expense to an ongoing operational expense, but that's the subject for a future post!