It took a while to get to done, but I’ve now sold my first microISV product – MasterList Professional – to Shohn Trojacek of SixTree for an undisclosed sum. Its new home is http://masterlistpro.com.
The two reasons I sold MLP were a) I’ve done a lousy job of updating it and wanted to pass MLP on to someone who could and would make a clean start of it and b) I’m cleaning house to free up time and mental energy so I can get Project X (StartupToDo.com) complete enough for a private beta, finish the rest of it with that feedback and launch before June 1st.
(The backstory here: I wrote MasterList to break free of contract programming for a living, wrote Micro-ISV: From Vision to Reality because I had no idea how to sell it and needed answers, and my professional career – perhaps my calling in life – has gone in a certain direction from there.)
Here’s what I’ve learned:
1. Before you launch, schedule time to get regular updates out. By schedule, I mean, carve out, commit to, and absolutely do. Getting updates out on a regular basis – something like every 2-3 months – is critical to future sales. Updates prove your software is alive, that you’re committed, that you’re listening. After the first few updates, I was so overwhelmed I could not bring myself to update MLP. The longer I waited, the more guilty I felt, the less I wanted to confront that pain.
2. Desktop microISVs worry way too much about piracy. Because I bought into worrying about piracy, I created a great registration/protection scheme that to my knowledge was never cracked. It also doubled the time I spent on tech support as people switched/reformated PCs and I needed to cut new registration codes for them. Plus, since 4 years ago I knew squat about creating a web app, creating new reg codes was a totally manual operation. Bad idea.
3. The feature you love is the one your customers will care least about. One of the most problematic parts of MLP when my company owned it was a checklist feature very, very few customers cared a whit about. I thought it was totally cool; the market could not care less.
4. Don’t build a new app on moribund programming language. After a decade of building VB6/VBA apps, I built MLP in VB6 instead of the then new .NET. .NET was untested, buggy, didn’t do anything you can’t do in VB6, blah, blah, blah. Whither it’s commercial controls or open source projects/libraries you use to push your language to the limit when doing commercial software, if they dry up, you are going to have an increasingly difficult time of it.
5. Good customer support does turn customers into evangelists. More than a few times, this happened with MLP.
So as I get StartupToDo marching, here’s how I think I should/have applied the -painful- lessons learned above.
1. Focus on the core selling value of your app. When next month StartupToDo goes live, there will be a base feature set that startups and microISVs will I hope open their wallets for, and not much else. See next point.
2. Startuptodo.com is a Rails app with plenty of jQuery goodness. That addresses the whole piracy, moribund language, registration code snafu, but given what it is, it makes total sense as a web app and no sense as a desktop app.
3. Improve regularly, but look to your customers for at least half of your strategic direction. I have a slew of features I’ve thought through/prototyped, but I’m going to take my lead from the community of customers as to what get’s built out. I will – despite all of the marketing I need to be doing – be setting aside non-negotiable time so I can release small regular incremental improvements about every 3 weeks, and will be looking for a talented Rails developer as my first significant expense to keep that going.
4. Don’t assume I know everything I need to know when it comes to building a startup. What worked then doesn’t necessary work now – that’s more than half of the reason I’m writing The Web Startup Success Guide (I’m 8 of 10 chapters done with the first draft). At least this time around, I’ll finish the book before launching the app!