Note: This is part three of a three part series about the single founder startup I have been working on over the last two years. Check out part 1 and part 2.
At this point I had one project fail I didn’t control and one project fail I did control. Once I had decided to abandon that project I was frustrated and aimless. In these times I tend to do two things: drink beer and write code (not necessarily in that order). I didn’t know what to do next.
And then there was Drupal
The projects for the firm I work with part time – Urban Insight – were increasingly based on Drupal. Drupal is a powerful, modular, and popular framework for developing a web site (less a framework for developing a web app). The community supporting Drupal is probably its greatest asset, quickly followed by the massive number of modules available for free to extend functionality, and the sheer beauty, power, and massive pain of the chaotic hook system architecture.
Drupal was surging ahead in popularity and within a very short time Urban Insight had a pile of Drupal-powered client sites that we maintained. I believe in being a zealous steward of technology for my clients. In Drupal, this means ensuring the Drupal configuration remains secure and tuned, and that security patches are installed quickly.
With Drupal’s power comes complexity, and this complexity can be hard to manage. When you have dozens of Drupal sites it’s hard to keep track of the core version, module list, and configuration of each one, and keep it accurate at all times.
So I had this thought. If I built a little web app dashboard to track all of our Drupal sites it would give us a single place to monitor the live configuration of every site we had. I threw together some mock-ups and on the (as I later learned) wise advice of Rework I tore out features that would take too long or were too hard (which really translated into hard to use, as I later discovered), and focused on what I could build in three months.
I got an alpha working and showed it to our CEO. He said he saw its value and committed to being the first customer, when it was ready to launch. I was excited. When I started to build this I honestly didn’t think it had potential as a business. I was just building it to make my life easier at Urban Insight.
Go marketing young man
I wasn’t going to make the same mistakes I made with my previous effort, so I tried to focus on marketing. I did learn how important the marketing was, but I had not learned how to market.
I remembered some advice I read previously about design: all designers start by ripping something off. So I ripped something off. For the home page, I found one I really liked (Pulseapp for the curious) and started my design by ripping of theirs. You aren’t doing anything unsavory in starting by copying because in the course of adapting it to your needs it becomes your own.
The other neat thing that happened in the process of copying is that as you replicate specific components of a design you start to understand why they did this little thing in this certain way and you have this nice aha moment or clarity. I am a lousy designer but starting by copying helped me design one order of magnitude less lousy.
I used this technique for the home page (thank you Pulseapp!), the tour page (thank you 37 Signals!), and the tips page (thank you again 37 Signals).
Do only what is important, or less really is less
I didn’t build payment integration until after the beta. I lied really. I launched the beta, said you could sign up for a paid place once we left beta but with no intention of building it unless people used the damn thing. I wasn’t wasting time.
I also resisted the urge to build an administrative app. You always need to build some kind of for admins to look at logs, see account information, and do various account management tasks. But these admin apps can be a real boondoggle. Giant charts and graphs are cool to look at, but do they actually help me get stuff done faster?
Using some advice I got (yet again) from Rework I decided to let need define development of the admin app. When a support request came in I forced myself to build an admin feature that would speed up troubleshooting the issue the next time it happened. This meant it took slightly longer to address a support issue the first time around, but we are talking only hours, not days or weeks.
With this pure need-driven approach to development the time it took to handle troubleshooting dropped tremendously. When an issue came in, I had a screen or a link that helped me identify the issue in a few seconds, instead of a few minutes of manual database hunting and pecking. It also led me to bake in as much self-help as possible into the app when things went wrong. When the tool encountered a specific issue with a user I was now able to have it return specific steps to address the issue. The most common issues really addressed 80%+ of the issues being encountered.
I had little support to triage, and when I did, it was easy to handle.
Droptor is born
The Droptor home page
I finally had it. A tool I needed, a tool I used, a tool others found useful, and a design that didn’t suck (too much). I launched the beast in beta, released the module on Drupal.org, got some users, and planned for launch.
I baked in payment processing, planned for launch day marketing, and ran a promotion for my current beta users to sign up before launch for a steep, lifetime discount. Several users took advantage of the offer.
Droptor launched on July 17, 2010. I released three major upgrades over the course of the next five months, culminating in a Droptor 3.0 release on January 2, 2011.
The product needs to scale in revenue
I imagined the Droptor customer base as being in two distinct groups that I would reach one after the other. The first group would be firms like Urban Insight, Chapter Three, and Phase 2 that do a lot of Drupal work and have many Drupal sites they need to maintain and support on behalf of their clients. There are easily more than 100 of these kinds of customers.
The second group of users would be organizations – like a university or a large company – where Drupal has grown like an infection from being used on a little project they had to put together quickly two years ago to conquering the home page. I’ve personally spoken to these IT departments and heard this story over and over again.
When I decided to open up Droptor to other users, I thought I had a clear idea of the customer base and the potential size of that base. I thought it was large enough to be a first step to build a small business.
But my assumption that a firm would have many Drupal sites to support on behalf of their clients proved incorrect. It now appears far more common that a firm will hand over a finished project to a client-side IT department. My plan was to use the revenue from the first customer group to reach the far harder second group was not working.
Marketing is hard
Yet again, I found marketing very hard. I ran a Google Adwords campaign for months that did drive traffic to the site. This kept a steady pace of free sign ups coming in, but after some time it was clear these were the wrong users. These folks were going to Google to figure out how to setup a Drupal site, and were using Droptor to help them figure that out.
I certainly don’t have any issues with these folks using Droptor for this purpose, and I would never stop them. But they aren’t the users who are ever going to set up a paid plan and track dozens on Drupal sites for their work. It wasn’t worth paying for customers that wouldn’t increase revenue. I stopped the Google Adwords campaign.
Being part of the Drupal community was probably the most valuable marketing I could do. Just posting the module on the Drupal.org site was valuable in getting attention. I also used Twitter to put a public face towards users and was able to respond quickly when users reported issues (and win public praise).
I also spent money on putting a glossy handout in the swag bag of every conference attendee for the 2011 DrupalCon conference in Chicago. This is the Drupal event of the year. A majority of everyone in attendance is a potential customer so I thought this would be a perfect marketing opportunity.
Sadly the ad had essentially no impact. The problem must lie with the product, the ad, or the marketing method. I had budget constraints so I had to design the ad myself. But even with that, it must be an issue with the product.
The DrupalCon Chicago Droptor ad
But the most disheartening moment with marketing came when I spoke with several people at DrupalCon Chicago 2011 who had the exact problem managing Drupal sites that Droptor was meant to solve, and stared at me blankly when I said “I have a tool that solves this problem.” For whatever reason, Droptor didn’t resonate. I really don’t know why.
I feel like I did two simple marketing things right. First, I setup Google alerts for “drupal monitoring” and “droptor”, an easy and well-known method to track conversations and opportunities to talk about your product. Second, I carefully tracked whenever praise came in – be it email, Twitter, or a support ticket. This made preparing marketing materials much easier.
The payment plans were wrong
In retrospect, I think another problem was the payment model of Droptor. The pricing module was $2 per Drupal site scanned per month. I came up with this model to make it easy for consultants to bill the cost of Droptor back to the individual clients they were supporting (assuming they had a fleet of Drupal sites for many different clients). What I didn’t realize is the cost was so trivial that passing along the cost didn’t matter.
I should have used a traditional billing model where there was a free plan and several paid plans for larger number of sites (with additional features made premium). This pricing structure would have made the tool seem more professional, and I believe the additional cost would have added credibility.
What I’m proud of
I’m happy with how two things came out: providing customer support and building a product. I made customer support the top priority above all other tasks and responded to issues quickly and completely. Nothing disarms a frustrated user faster than a rapid response, honesty, and an “I’m sorry.”
I am also proud of the fact that I built a real product, maintained that product, upgraded that product, supported that product, and got a (few) people to pay for that product. The feeling of getting paid for an act of pure creation is amazing.
Where Droptor is today
I am averaging a little less than one free sign up a day (during the week), and very few paid sign ups. As of this writing, we are syncing over 450 Drupal sites for over 400 users. We have about 25 paying customers. Droptor revenue is very modest, but does cover our expenses (other than time) of hosting, backup, and payment processing.
Revenue isn’t growing, and I am no longer convinced that revenue can scale. It’s decision time. Refocus and continue to work on Droptor or discontinue it and move on.
Major lessons learned
Most or all of what I’ve learned is already out there, but these lessons are all personal to me so I want to share them here clearly. The lessons are:
- Build something you will use
- Google Adwords will get you traffic in exchange for money. The critical question to answer is, “Is it the right traffic?”
- Use a standard pricing model, with plans based on size and extras for the higher plans
- In design, copy something good. If unsure, find a similar work you like and start by copying it
- Use a Twitter account to provide easy communication to users
- Spend almost as much time building the marketing material for a feature as you do to build the feature
- Communicate value to potential users, not features
- Have a guaranteed first user. Fuck, have five
- Let necessity drive development, not wish list
- Let pain points guide your efforts
- Hard to make features are probably hard to use
- Easy is hard, so focus on that instead of hard-to-build features
- Track testimonials and current clients for use in marketing
What is next?
I have no idea.
The failures have been incredibly frustrating for me on a personal level, though very educational. I would love to work with a larger team on a new project. I really don’t know why, but I can’t wait to try, try, try again.