I just heard Canada is dropping the penny – it costs the government more to make it than its actually worth. So does this bring an end to psychological pricing – no more $9.99 offers in Canada?

Software Pricing

Legally speaking, retailers would be obliged to round prices to the nickel, but only for cash transactions – not for online payments. So software vendors could still price products as they do now, if they sell online.

How is Software Priced?

This made me wonder how software vendors are pricing their solutions. I came across some interesting trends:

Most lower-priced software use granular pricing ending with .99 or .95 cents. Most of the Mac only products have pricing down to dollar amount – e.g. Coda from Panic software at $99.

Higher-end software products are priced to the nearest dollar, usually ending in nine dollars. Surprisngly some vendors still show .00 trailing amount – which is unnecessary and looks ugly.

Software-as-a-Service vendors tend to stick with whole numbers. I think they might be afraid that SaaS pricing requires mental math (monthly price x users x bandwidth + addons, etc). So they prefer to use “math-friendly” prices.

Last but not least, have a look at the app stores from Apple, Google, RIM and Microsoft. All apps are priced with a trailing .99 cents. Most apps are sold for less than 10 dollars, so I guess at such low prices, the penny makes a difference.

Is your company thinking of deploying a mobile app for its web-based service? Here are a few tips on how to get started (many thanks to Dave Bergevin from EventKaddy.)

Platform Support

The first point to consider is what phone platform to support – iPhone, Android, Windows, BlackBerry or the whole lot? Its best to examine your target market and ask what phones do they use? Can you narrow them down to a specific platform? If not then you may have to develop the same App in many different platforms – which can be a serious undertaking.

Native or HTML5

If your app requires mobile hardware capabilities (compass, camera, gyroscope, etc) it’s better you develop native (iOs/Android/BB-OS, etc.) It’s most likely that you don’t need these since yor SaaS tool could live without it. In that case consider HTML5.

One code base

HTML5 allows you to have a single code base that can be rendered consistently on many different platforms. On devices that allow for HTML5 local caching the user experience can be appreciated offline as well. The HTML5 option also saves you from resubmitting your app to the AppStore/MarketPlace/BBWorld each time you change content in the app.

Develop in 5 – Deploy in 6

A very cool framework that allows you to code with ease is PhoneGap. It lets you code in HTML5 and provides near-native support in 6 phone platforms. PhoneGap wraps your HTML5 content inside an app and uses the built-in browser of the phone to render the screen. Makes for an enjoyable user experience without you having to worry about maintaining many code bases.

Whatever technology you decide to use, remember the app must be designed with the same principle as your original SaaS tool. Build it on user experience and functionality – not the novelty of it being an App.

I was looking at Mamut, a company recently acquired by one of my clients. Mamut offers installed/on-premise software. So I was surprised to see a message asking visitors to test drive the software on the browser.

I filled out the lead capture from to see they were using Runaware, a citrix-based platform. With this, you can view an instance of Mamut’s desktop client. That’s a pretty cool service. You get to view a full-fledged working copy of a complex system within 30 seconds.

From a lead-generation point of view, this can be an effective way to capture leads who prefer an hands-on approach. Runaware also captures analytics so that you can see what features your lead spent time on. Pretty neat!