May 11 2011

In which I build something I don’t use (Act 2)

Published by at 9:30 am under Programming,Software,Software Industry

Note: This is part two 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 3.

Why I’m doing this.

Before I dive and talk about the next app I launched, I want to be clear on what my goals are in starting a web business:

  • I like building stuff on the web. I have been coding and using computers all of my life.
  • I want to build permanent support for the work/life balance that I have found is most productive for my output.
  • I want to be in charge.
  • I want to be business for 30 years, not three.

Now, in terms of my goals for money I really, truly am not doing this to get rich. I am doing this to make money, though. But money to me means slowly growing a company over time and making it profitable on day one. I’m not interested in selling a business to Google or Facebook, and I am not setting out to build something I think they would want to buy.

I’m interested in profits, margins, and value. My business heroes are Warren Buffet, Jason Fried, and Joel Spolsky. I don’t care about social networks or photo sharing apps. I don’t want a $10 million dollar funding round. I don’t want an audience before I have revenue. I want to run a business that makes profits and does cool stuff, building a team of like-minded people over time.

The idea

Prospector App home page

The home page of Prospector App

I designed and led the team that built several internal web applications for the higher education market. One of these was essentially a customized CRM for admissions recruiting. Perfect, I thought. The value of a CRM in an organization is proven – look at Salesforce – so organizations will want them. I could combine my domain knowledge of higher education admissions with having already built a web CRM for recruitment. Sweet.

So I started coding. And coding. And coding. And designing (poorly). I took the premise of what I had learned building an internal .NET app for recruitment, took out the stuff I didn’t think made sense (the peril of services), and rebuilt it as a multi-account web app with the excellent CakePHP framework.

Development wasn’t hard, except for the payment integration. I don’t know what it is with payment gateway vendors, but the APIs are usually painful (Authorize.NET, I’m looking at you) or the multitude of plans is very mind-boggling (read: Paypal Propayments Flopro Webmasters Elite). Integration is a pain, testing is a pain, and handling all of the edge cases is a huge pain.

I wanted people to be able to upgrade, downgrade, and cancel in the application, without having to contact support. This took more time than I wanted to allocate. In retrospect, I should have launched a free beta and waited to build payment integration if people signed up. This is a valuable lesson I didn’t fully learn until this happened and I read Rework by 37 Signals (an excellent book, highly recommended). Solve real pain points, not anticipated ones.

My Three Major Mistakes

I finished the thing. I had my head deep underwater, coding for several months, happily working away. Then I actually finished it and I had no idea what to do with it. I didn’t need to use it myself, I didn’t know how to market it, and I didn’t have any good connections to the community of potential users (higher-education admissions professionals). I had this big thing, and I had no idea what to do with it.

Of course I had read about the danger of building something you didn’t use, but I didn’t really understand why it was so bad until I experienced firsthand. If I had a co-founder who had connections or access to the admissions community, it would have been a far different experience. But I didn’t, I just myself, my code, and my time. Once the thing was done I had no idea what to do with it.

Another major mistake was not caring about the design of the public pages for the application. I didn’t spend much time thinking about how to market the product on the web site itself, or even how to market it generally. The design sucked and I had no idea what to do next.

I think the mistake with marketing came down to the fact that I didn’t start thinking about marketing on day one. In retrospect, I should have kept this in the back of my mind during development. When I finished a feature, I should have adding it to a tour page, or a FAQ, or something. But I didn’t. I just put marketing off to a later stage. I will worry about that later, I thought.

The final major mistake was that I didn’t have a guaranteed first customer. A guaranteed first customer is a friend or a colleague who both needs the thing and would be happy to try it in production and give you feedback. I didn’t have anyone who I knew for certain would be the first user. This should have been a major red flag, but I missed it completely.

To summarize, I made loads of mistakes on this project, including:

  • Spent too much time on payment integration before the product was proven
  • Built something I didn’t need or would even use
  • Didn’t have a connection to the community of potential users
  • Put marketing off to the end instead of making it part of the process from day one
  • Didn’t have a guaranteed first customer

The project stalled on completion. The technology was finished, the code was complete, but so was the project. I moved on to Act 3.

No responses yet

Trackback URI | Comments RSS

Leave a Reply