When we left Part 2 I had fixed 23 bugs and released the next version, DotNetInvoice 2.1, to the existing customers. The release included a fix for every known issue. Customers felt supported, and a few new sales rolled in. Things were looking up until the end of the first month rolled around.
What Sales?
The funny thing (not funny “haha,” but funny like you feel after eating Sushi from a street cart in Mexico) was that after four weeks of sweating bullets, fixing bugs, and dealing with angry customers, sales were quite a bit below previous months.
Given the extensive conversations I had with the former owners I was confident their numbers were correct. But I could not for the life of me explain the sudden drop in sales.
After emailing a few customers I began to put it together: when the developers had released version 2.0 a few months earlier they had a large block of the 1.0 customers lined up to purchase it. In fact, many of them pre-purchased the product at a discount.
When the product released the flood gates opened, revenue shot up, and gobs of version 2.0 went out the door. The month I took over was one month after sales had stalled and the bug backlash began. My timing was impeccable.
The end result? I overpaid for the product. It wasn’t a huge amount of money, but it did sting.
Present Day
Flash forward seven months.
With two more releases under my belt and a heck of a lot of marketing, monthly revenue is nearly triple its previous levels, and DotNetInvoice 2.3 is a solid piece of software.
Written in ASP.NET 2.0 and SQL Server 2005, it includes source code and a 30-day money back guarantee. In the last seven months my team has implemented dozens of new features and performed some major refactors (important when selling an open source product).
We even received a 4-star review from asp.netPRO magazine.
My Advice When Acquiring a Software Package
- Spend a lot of time working with the code. I’m a five year veteran of .NET and I had a pretty in-depth look at the code before making an offer. The code was clean, consistent, and worked as expected. What I didn’t do was perform a complete install and thoroughly test the software (or hire someone to thoroughly test it). It would have taken several hours to get into the meat of the app and really get my hands dirty, but I trusted that since the code was clean that it functioned well. Bad assumption.
- Email current customers. You’re spending a lot of money on a product that, even if you’ve spent time testing, could still have fatal flaws only noticed by someone who’s used the product for months. Ask for 5 email addresses and contact customers, asking them everything: how they purchased the software, how much they paid for it, how helpful the support has been, how many bugs they’ve encountered, and how many have been fixed. The answers will be invaluable when extending an offer.
- Attack the demo. Don’t be smitten by the emotional aspect of a demo (such as the glitz of AJAX or a slick design). Get in there and break the thing. Enter thirty digit dollar amounts, try a SQL injection attack, or lob rotten tomatoes at it from 10 paces. If the code was well written, the back end should gracefully handle any garbage you throw at it. If not, drop that offer by a few percentage points.
- Investigate revenue and expenses for the previous 6 months. Look back as many months as you can. If a month is not available assume it was terrible and adjust your offer accordingly. Take the average monthly revenue from the previous 6-12 months to eliminate seasonal or “new version” peaks. If the product is relatively new, assume revenue will drop after the first 2-3 months. If there’s a lack of information, assume the worst. As a general guide, products like this tend to sell for between 12 and 30 months of revenue.
- Fix bugs quickly to earn customer trust. If you discover your new product has bugs, fix them quickly to show customers you mean business. One advantage to acquiring the product was that everyone was patient with me since I was learning the product along with them. Customers were surprisingly respectful because I was willing to spend the time to help them. Remember that these customers are your lifeblood. Even though they’ve already paid for the product, they can help you in more ways than you realize. Early on, they know the product better than you do.
- Clean up around the edges. It’s very possible you will inherit a solid product that’s rough around the edges, such as one lacking documentation or a decent user interface. Providing installation instructions or improving the look of the application are ways to impress present and future customers.
[tags]asp.net, .net invoicing, software startups[/tags]
