Design Limbo

So you have your new and shiny application you just finished building and your trying to get people to try and buy it. But as a technologically savvy person you know all about the cracking and pirate scene, and you don’t want your app out there. Your not foolish to believe that whatever scheme you come up with won’t be cracked, so what do you do, not put out the demo at all?

Your protection scheme will be cracked, no matter what it is. But you have to figure out the value/effort curve, if your software is only $9.95 and protected by a decent protection scheme, chances are your not going to find it cracked. But if your software is in demand and costs $299.95 it will most likely be cracked.

When someone cracks your demo software they are by-passing your protection schemes and enabling the full functionality of your application. This could be enabling features, disabling time bombs or any other measures to try and get people to pay up.

But I have another suggestion for your, build a specific demo version of your software, that doesn’t have the code for the other features at all! NDepend does this and I’ve never seen a real cracked version of it out there, because the code for those other features isn’t there, there’s no way to enable it.

If your building your software in a modular way, you should be able to create sub-sets of your code and your application picks of the differences.

For example I put the valuable code in separate projects and register them with StructureMap.

My full project, has 25 separate .cs generators files in it that contains the useful stuff, but my demo project only contains 2 (NumberGenerator and StringGenerator)

This assembly compiles into the exact same file as the full version and will get swapped out before I secure the project with {SmartAssembly}, at no time will my full versions of the code be in the demo project, which in startup will pull all of the available features and present a limited set for the demo.

I’ve also been playing with a system to compile a full version of the product on demand (when someone buys it) which will embed customer specific information into the code base, allowing me to determine who leaked the full version out and revoke their license and possibly recoup my looses.

If you are going to produce many software products you shouldn’t protect them all the same way. Your low end software can be protected by a licensing key system while your higher end software is code limited and compiled on demand. You should always try and have a demo, or free version of your product out there, but be smart about how you do it and it will be a benefit and not a potential liability.

In my previous post I talked about Neil Davidson’s book about software pricing. One of the principals in one of the final chapters was trying to convey how much your software cost to make, or how much of an investment you’ve put into it. Which I took to heart and tried to analyze one of my newest projects to see how much it cost me to develop it. I failed.

There are a couple of reasons I don’t believe that I was successful on trying to get my cost out of my project. I first tried looking for a software product that I could use to do this for me, by analyzing my codebase and letting me plug in additional numbers, there weren’t any.

Failing to find a white software knight I turned to the OSS community to look for solutions, as I know Ohloh has something that estimates cost for OSS projects called OhCount, it wouldn’t work for me being a MS developer, and there weren’t any other OSS tools that would work against my codebase, or that worked at all on my box.

Most tools I found were metric or analysis tools for your codebase, these are Lines of Code tools. This sounds great but not all code is equal. For example my XAML code is harder for me to write then C# code, so it’s actually more expensive for me to write XAML then C#, as it takes more time and resources.

One of the key software project cost estimation formula are is the COCOMO/COCOMO II cost model, which if applied correctly I think can get you into the ballpark of your software projects cost.

Cost estimation in software projects is a huge area and a major problem and you will never be 100% accurate. There will always be cost that you miss, or items that you over-estimate and if you have more then one person working on your project then using a straight LoC formula won’t take into account that developers strengths and weaknesses in relation to the code they are working on.

My software project isn’t finished and here are my basic COCOMO metrics:

I’ve only been working on the project for about 2 1/2 months and then only few a few hours here and there, but in a way I think it could line up. To get a true cost I would have to factor in resource usage (power, bandwidth, computing resources, etc) and many other hidden costs that are difficult to determine and quantify.

All lines of code, even from the same developer are not even and thus fixing a cost per LoC is inexact to say the least. But without anything better, it’s a decent starting place. So at a minimum try and get your software projects cost to help you plan how much to see it for and when you will break even in that expense, and you might also be able to use it to help market your product as well.

I recently stumbled across a book by Neil Davidson called “Don’t just roll the dice: a usefully short guide to software pricing”. It’s an amazing read and prefect in length, you could pick it up and finish in about 30 minutes, or if you a painfully slow reader like myself, an hour. The book focuses on software pricing and a way of going about it.

I think this is a vital topic to anyone wanting to break into the software market, and eventually trying to sell their software. I’ve seen far to many software products horrible overpriced and think they could sell much more by lowering their price a little.

But this depends on your target audience, if it’s individuals or cash strapped small companies or startups, charging hundreds of dollars for your software might not be the best idea. But if your targeting major enterprises, your fifty dollar product could probably sell for much more.

Neil touches on this pricing demand curve in Chapter 1, and provide a great basis for the rest of the book. Armed with some basic economic and target customer knowledge you can start to develop a cohesive pricing plan for your software. Neil mentions in chapter two that your software is more then just bits and bytes, and a nice GUI. Your product is documentation, support, development roadmap and so much more. In my opinion your product is also your company and the community surrounding your product, company or people.

In one of my Licensing System reviews I found a great licensing application called EZIRIZ IntelliLock. It was priced right, had the right features, but the company wouldn’t respond to my sales emails. If they can’t do that when I dangling money in their face what kind of support will I get when I bought the product and have a problem.

When your developing a product you should look at the marketplace and your competition. Figure out how much they charge and how closely the software maps to your product. But don’t analyze it in a vacuum, take into account the size of the company, it’s community and your perception of the value of the ecosystem around that product. Established products from larger well known companies can change more, even if your product is better you might consider selling it for less until you’ve made a name for yourself and your product.

Customers will compare, especially with the Internet. So if your selling your software more then your closest competitor you have to make sure you justify it to your potential customers with more features, better documentation, a larger community, etc.

As developers we like things round. So Selling software for fifty bucks even is great, none of those messy pennies flying around. But as Neil points out, fives and nines exert another powerful psychological effect on peoples perception of value.

Give Neil Davidson’s book a read and buy a physical copy if you enjoy it. You’ve spent tons of time designing and creating your product, now your only quarter the way there, now you have to market it, sell it and support it. Developing it was the easy part!