In the last post about our Cloud Storage Studio/e product, I mentioned how we stopped working on that product in favor of a desktop based product. In this blog post, I will write some details about building a product which turned out to be the flagship product for Cerebrata – Cloud Storage Studio.
Core Technology
In this section, I will talk about the technologies we used for the development of this product and why we chose those technologies.
Windows Presentation Foundation
For the development of this product, we used Windows Presentation Foundation (WPF) instead of Windows Forms. The reason we chose WPF because we had already built 2 applications (Omega.SDSClient and Cloud Storage Studio/e) using Silverlight and we felt quite at ease with WPF. We didn’t do this because it was a new and bright and shiny piece of technology.
Wrapper over REST API
Windows Azure Storage team has provided REST based API to manage all aspects of Windows Azure Storage. We actually chose to write our own wrappers over this API. In fact we did most of that work during the development of Cloud Storage Studio/e so we just tweaked it a little bit to work with the desktop application.
There was a .Net based Storage Client Library also available at that time which was also a wrapper over the REST API but we chose to implement our own simply because I found the library too complicated to understand (This was only because I didn’t have much experience working with modern .Net applications and the 1st time I saw “Context” and other things, I kind of freaked out 
).
In retrospect, it worked out well for 2 reasons:
- We wrote the code that we understood so it was easier for us to maintain and enhance that code.
- Later on we noticed (and it is still true) that the changes came to Storage Client library came much later than the changes to the REST API. Being a tool vendor, it was of utmost importance for us to provide the latest features as early as possible and by choosing to write our own “Storage Client Library” allowed us to do so.
IMHO, Technology decisions are important (actually very important) but at the end of the day you should feel comfortable with the choices you make as in the end you’re one who would need to support that. Furthermore don’t get hung up. You’ll get ample opportunities to rectify your mistakes. To give you an example, version 1 of Cloud Storage Studio was developed with no framework/design pattern. We just went with “Whatever rocks your boat!” attitude but when we worked on version 2 of Cloud Storage Studio, we rewrote the application using MVVM design pattern.
Initial Development
Like with the other products, our motto was to get something out quick and then iterate over it fast. We started working on the product sometime around March/April 2009 and were ready with the 1st cut around May/June 2009 timeframe. We only provided limited features (tables and queues management) in the 1st cut. With whatever we built for v0.1, we decided to go in closed private beta.
Closed Private Beta
Since we wanted close interaction with our users, we decided to go with a closed private beta. I created a simple web page on our website asking users to provide their names and email addresses and then I posted a thread on MSDN forums for Windows Azure announcing about the availability of this product and asked users to sign up for that. By the time we were done with the private beta, we had over 300 beta users using our application.
V0.1
This is how our application looked like in V0.1 . I have highlighted some of our “Strokes Of Genius” in the screenshot below.
A few things we did (and got beat up pretty bad by our users):
- The application was launched in full-screen mode. That would prevent users from doing anything else other than using our application.
- On purpose, we stayed away from “Menu” driven approach and opted for Windows “Orb” approach. Our “lame” reasoning (and I kid you not) was that let this application be the “Operating System for managing your cloud assets” . And with all of our “Genius” thinking, we put this “Orb” right where you would find Windows’ one.
- On purpose, we stayed away from “Tabbed Windows” approach and implemented our own “Windows” stacked at the bottom bar.
- It was not all bad
- . At least ours was the first tool which would allow you to edit/add/delete entities in a table and I think the beta users were a quite considerate. Anyways, folks started signing up and feedback started pouring in. One of the 1st feedback we got was on the “Orb” thing which we fixed in the next release.
V0.2
This is how the application looked like in the next version.
We learnt from our mistakes (or rather made to learn from our mistakes ) and fixed those. We moved the “Orb” up on top (but still kept it ). Got rid of full-screen mode of V0.1 and added support for blob containers. With that version, our users were able to upload blobs in blob storage.
Again, we did few right things like supporting chunking of blobs for uploading large blobs. That eventually became one of the USPs of the product. Also we got rid of some of the place-holder features like upload database etc. which we implemented later on. IMHO, there’s no point in providing “Coming Soon” kind of things in an application. What’s the point in making a user click on a button to be presented with “Coming Soon” window especially when you’re closely interacting with your users.
V0.3
Windows Azure was evolving and so was Cloud Storage Studio with that. For example, between the release of V0.2 and V0.3, support for Shared Access Signature was announced by Windows Azure and we ensured that the product has support for that feature. Now we started to realize the benefit of gamble we took by rolling out our on Storage Client library as we were able to implement these new features in our library earlier than the library provided by Microsoft.
Somewhere between V0.2 and V0.3, we got the best feedback we could have asked for which essentially changed the course of our development from the UI development point of view. I’ll share some of those below:
Those were literally eye-openers for us. I can’t say how grateful I am (to this date) to the guy who gave this feedback. Basically it made us go back to the drawing board and made us do the UI from scratch. We did that in V0.4.
V0.4
This is how the application looked like when we released V0.4.
Based on the feedback we received, we decided to go with more “Sql Server Management Studio” kind of approach with tabbed layout and all.
One important lesson we learnt in the 4 releases we made is “Don’t Make Your Users Learn How To Use Your Application”. If you’re doing that, there’s something wrong. We tried hard but unfortunately it’s a very tough nut to crack and till date we’re trying to make our software easy to use.
Public Beta
We kept the application in private beta for a few months and went through 4 iterations. At that time we thought we are ready to go into public beta for the application. With that intent, we opened the application for general public around October 2009. During the private beta phase, I used to zip the application binaries and send the link to download this file to our users. When we went in public beta, we decided to deploy the application using ClickOnce deployment mechanism. Again, we didn’t know anything about it. Our users recommended it, we thought about it and it made sense for us to do that.
We made 5-6 more iterations during public beta phase between October and December and with one of those releases, we kind of made our product name “Cloud Storage Studio” irrelevant!!!
In PDC 2009, Windows Azure team announced the public availability of Service Management API, which is a REST based API for managing hosted services and applications deployed in the cloud. In fact Windows Azure Portal made use of the same API. We thought about the best place to implement this API (in Cloud Storage Studio or build as a separate tool) and finally decided to implement it in the tool itself. So now apart from managing Windows Azure Storage, one would also be able to manage their cloud applications using this tool. Thus “Cloud Storage Studio” name kind of became irrelevant however we continued with it as folks were familiar with the tool name and it would have been somewhat of a tougher task to manage 2 separate applications.
For implementing the Service Management API, we didn’t do anything crazy. We looked at Windows Azure Portal and how the functionality worked there and implemented the functionality in our tools very much similar to what was done there. Again this was done to get wider acceptance and easier adoption. Essentially our mantra has become “Don’t Make Your Users Learn How To Use Your Application”.
All in all, things were going great. Our tool was used in various demonstrations in PDC. Folks started writing blogs about us. All of these were big deals for us.
We had about 700+ users participating in public beta. We thought it was time for us to start thinking about going Live with this product.
Go Live Preparations
We decided to go live with this product on January 1st 2010. In order to do that, we had to take care of a number of things including but not limited to pricing, licensing terms, and website etc.
Pricing & Licensing Terms
We were absolutely clueless as to what should we charge our users for the product. Should we charge $50 or $100 or even more? Should we go with perpetual license or go with annual subscription based license model? There was a lot of confusion regarding this.
This is where my association with Red Gate began. I happened to read a great book by Neil Davidson who’s the Co-CEO of Red Gate. The book was called “Don’t just roll the dice”. It’s a great book for software pricing and best of all you can download the e-book free from Neil’s website: http://neildavidson.com/download/dont-just-roll-the-dice/. I got great insights from the book. I also wrote him asking several questions and he was kind enough to respond back. That helped me a lot.
I’m also a big fan of Peldi from Balsamiq. I wrote him as well and got really good feedback from him also.
There’s a saying that “Beauty lies in the eyes of beholder”. Following this saying, I actually approached some of our users and asked them how much they would be willing to pay for the software. No, they didn’t say “Nothing” but they gave us some really good guidance. To my surprise the price range we had in mind was very much aligned with what our users were willing to pay for this software. Another thing we found is that the users we sought opinion on pricing appreciated the fact that they’re involved in something which is typically considered a very internal process.
Another deciding criteria in pricing and licensing terms was the fact that we were kind of unknown as software vendors. We did not have a history of selling products. To keep matters simple, we thought that we’ll start with $50.00 and incrementally increase the price. Again to keep matters simple, we decided to go with “Perpetual” licensing i.e. the upgrades of the product will be made available free of cost for the life-cycle of the product (which I thought was a maximum of 2 years).
Licensing Software
Next thing we had to worry about was the licensing software which would generate license keys which we would sell. I started looking at all the licensing software available in the market and kind of fixed on the licensing software from one vendor. We tried it out and it worked quite well. Pricing was a bit high but nothing insanely high. We were ready to purchase the software and while I was sitting on their shopping cart page having the licensing software added to the cart, I saw an input field for “Discount Coupon” and I thought let’s search for any discount coupons available on the Internet. However when I searched for the discount coupon, I landed on a blog post by one [unhappy] user of their software. The software did not work as per the expectation of the user and what I saw was “blame-game” being played between the user and the vendor. The whole episode showed the vendor in a very poor light and obviously it raised red flag for us. Needless to say, we didn’t buy that software.
The reason I mentioned this episode here is because we learnt a great lesson here. It is extremely hard to earn a customer’s good will and it is even more harder to maintain it. Now I am not buying into the cliché that “Customer is always right” and you should always do whatever to please the customer but what I learnt is that one should never get into a public argument with one’s customer. During the course of selling our products, we have had one or two issues where a customer bought a license for one of our products and then realized that the software will not serve the purpose. Despite of having a “No Refund” policy, we always refunded money back to the customer in case our customer didn’t find the software useful. The rationale is that since the customer didn’t find value in your product, you have already lost her/him. Why piss the customer more by not refunding the money?
Anyways, our search for licensing software continued and finally we managed to find a great licensing software surprisingly through that blog post I mentioned above.
Evaluation Period
This was another thing we had to consider. What should be the ideal trial duration – 7 days, 15 days, 30 days or even more? Finally we settled for 30 days as we felt it is good enough time to try the software out.
Payment Processing
Next up on our list was payment processing. One thing was very clear. We did not want to do anything with user’s credit cards. We wanted somebody else to handle that. We looked at a number of vendors which provided payment processing and finally settled for FastSpring. Their rates were decent, workflow was easier to implement and their service was excellent.
Website Changes
Once we figured out all of these, we started making changes to our website and were ready to Go Live!!!
Going Live
I will always remember 31st December 2009! Came from a New Year’s party and flipped the switch, did a test transaction and went to sleep keeping my fingers crossed all the time . Not too concerned as we were not expecting any sales to go through in the 1st month considering we have given 30 day trial to all users (but we were wrong ). We gave out complimentary license keys to some of our private beta users so we knew the license key activation works. Also we did some test and real transactions, so we knew the payment processing works.
It was really good to see the efforts we had put in the last 8 – 9 months come to fruition. All we could do is wait and watch. Luckily for us we didn’t have to wait longer .
1st License Sale!!!
Like I said, since we had given a 30 day trial I was not really expecting any sales in the 1st month. But guess what, we sold our license on very first day!!! We had our 1st license sale on the evening of January 1st. Made $50.00 (rather $49.99) on the very first day. Extremely satisfying! Insanely elated! I don’t think I would ever be able to describe that feeling.
In the first month, we sold close to 60 licenses and made about $3,000 .
Party Time!!!
To celebrate the product launch and first few license sales, the team went out for a really fancy lunch!!! Special occasion called for special celebration .
Post Launch
When we launched, we knew that our product was not complete. There were a number of things we wanted to do with the product. But we knew that we’ll never be able to build “The Perfect Product”, we decided to draw a hard line and went live with one stable version. Once the euphoria of selling licenses in the first few days settled in, we again went back to work and started working on the new enhancements and fixes.
In the 1st month alone, we released 4 patches (one every week)! This trend of releasing in small patches continued for a long-long time and with all of our applications.
Lessons Learned
Apart from bolstering our belief in learning from our previous products, there’re a few things I learnt during the 8 – 9 months I spent on working with this product.
Choose the technology you’re comfortable with: When developing a product, you’re not in a “Super Cool Developer” contest. It’s better to play safe than be sorry later on. However one must do full due-diligence before zeroing on a particular technology.
Understand your user base: This again goes with the “Super Cool Developer” thing. Identify your target audience and understand what they’re comfortable with (this obviously does not apply to Apple ). Don’t try and make them see your way. Rather, you try and see things their way. This will reduce the on-boarding friction considerably and will result in wider adoption of the products.
Keep things simple: When you’re launching your 1st product, try to keep things simple. Don’t get all obsessed about nitty-gritty of pricing, licensing etc. Remember, the more complicated you make the harder you’re making for your users to use your product. Also you don’t know if your product is going to be successful or not at the time of launching so why worry about non-essential things at the time of launch. Plus these are “Good Problems” to have and you’ll get ample opportunities to fix them.
Be Humble: This is something I learnt when I interacted with Neil and Peldi. I wrote them emails out of the blue and despite their super busy schedules, they took time out and helped me. They could have simply ignored me but they didn’t. They offered all the help they could. I’ve run into folks who fall on the other side of this spectrum (read being completely assholes) and trust me you don’t want to be there.
Engage with your users as much as you can: Within the context of your application/services, leave no stone unturned engaging with your users. Always remember that they’re using your products/services. Any inputs you can get from them is going to enrich your product/service.
Never get into an argument with your customers publicly: Even if you think you’re right and the customer is wrong, never ever get in argument with your customers publicly. With the licensing software episode, the vendor had already lost that unhappy customer but then the vendor lost me and other potential customers as well by engaging in a public spat.
Celebrate!!! No success is small: When we launched our product, we didn’t wait for it to be extremely successful to celebrate. Every success, big or small calls for a celebration. Celebrate it!! Work hard, party even harder .
Summary
So this was the story of our Cloud Storage Studio which kind of made us famous in the Windows Azure community. In the next few posts in this series, I am going to talk about the other products we built.
So Long and Stay Tuned!!!
