CaseDetective for FogBugz is coming along nicely, there are still a few features to implement, but I’m getting there. It won’t be too long now until I can release a beta. Can’t say for sure what that time frame actually is, but I’m hoping it’ll be before the end of July.

Yesterday I made my first hint that CaseDetective existed in Fog Creek’s FogBugz forum in response to one of the most commonly asked questions; “what about reports?”. Today, in a follow up reply I decided to actually mention CaseDetective’s name, and give a proper URL to where my company site is (http://www.imijsoft.com) and said to contact me if interested in knowing when the beta is ready. I’ve had instant feedback, a couple of people have already dropped me a line via the new website saying they’re interested, and it’s not even lunch time in New York yet 🙂

So, now the pressure is really on, I’ve got to get it out the door and into the hands of some people that are actually interested in CaseDetective for FogBugz. It’s kind of scary, but very exciting too.

This excellent interview on DrunkenBlog with Brent and Sheila Simmons, a.k.a Ranchero Software, the makers of NetNewsWire, MarsEdit and other great software for the Mac, is a really nice insight into the life of a successful independent software vendor.

A definite recommended read.

microISV.com has pointed out indirectly that Annalee Newitz has written a very interesting white paper as a “A User’s Guide to EULAs”, with Donna Wentworth commenting on some excerpts. If you have ever scanned through a End User License Agreement (who actually ever reads them properly) and just clicked “Accept” to get past that load of legalese without a second thought, you might like to reconsider this approach in the future. There’s some really scary stuff in some of the examples, in some cases you can’t even share your opinions about a product publicly once you’ve accepted the license. In the case of a Beta program you can be quite happy about this, it’s understandable that the company doesn’t want their unreleased software talked about, but this is fully released software we’re talking about.

Number 6 on the list of nasty clauses is the ubiquitous “We are not responsible if this product messes up your computer.”, and this is basically the only clause that I’ve thought about including in my EULA. Here’s what my EULA was going to be before reading these two posts:

Terms Of Sale And License
*IMPORTANT* Please read the below carefully *IMPORTANT*

IMiJ Ltd grants one person per user license purchased the use of this software on one or more personal computers.

Every effort has been made to make this a quality and feature rich application for you to enjoy. However, you install and use this software at your own risk and indemnify IMiJ Ltd against any claims should installation or usage of this software result in loss or damage of any kind. If you do not accept the terms of this license please do not install or use this software.

This software is covered by a 90 day no questions asked money back guarantee. If you wish to surrender your license, please contact IMiJ Ltd at customer-service@imij.co.uk with details of your order number and serial number and we will refund your money and disable the serial number as soon as possible.

What do you think, is this a fair license? I tried to make it as simple as possible, clear and to the point, but after reading the linked articles, I might end up saying something like this:

Terms Of Sale And License
*IMPORTANT* Please read the below carefully *IMPORTANT*

IMiJ Ltd grants one person per user license purchased the use of this software on one or more personal computers.

Every effort has been made to make this a quality and feature rich application for you to enjoy, if it does something that you didn’t expect or don’t want, please don’t take me to court! Be excellent to one and other!

This software is covered by a 90 day no questions asked money back guarantee. If you wish to surrender your license, please contact IMiJ Ltd at customer-service@imij.co.uk with details of your order number and serial number and we will refund your money and disable the serial number as soon as possible.

What do you think, an improvement?

In a previous post I mentioned that I was wondering whether I should contact the vendor of the web app that I’m writing my Desktop app to work with, I was worried about whether they would like the idea or not, whether they would think I was just taking advantage of their hard work.

Yesterday I finally plucked up the courage to send an email to the vendor. They replied within about half an hour, when I saw the reply so quick I couldn’t help thinking it might be a pretty terse response. I shouldn’t have been so worried about their reaction. Although I won’t tell you what they said as I feel that is confidential, I think I can say that they were very encouraging about the idea, and offered to help me with any problems I might have!

I can’t tell you how much of a weight off my mind it is to know that the vendor is more than happy with me writing an app to work with theirs. I really should have known better, the guys at Fog Creek are great, always very helpful, and very pragmatic. Just what you’d expect from the company run by Joel Spolsky.

Yes, you read it right, I’ve let slip what I’m actually doing, don’t faint! 🙂 I’ve decided that I’ve really got no reason to keep secret what I’m developing, and as my good friend Gordon pointed out in his comment to my “The Big Think – Part 3” post, I may even get some feedback from the user community. And as I’ve said before, feedback is King.

I’ve been suffering from a spell of lost focus recently, just haven’t managed to get going on developing my app, and have been having some (continuing) problems in deciding on the app’s initial feature set.

This is probably one of the most common reasons in delaying and possibly even killing a new product, because if you don’t know what the product is trying to achieve, and for whom, you lose focus and start developing features that may be irrelevant and really have no product as you have not properly identified the market.

With Christmas and a faulty video card on my development box introducing some time away from development for the best part of the last month, I’ve had some time to re-think my product’s focus, who I am making the product for and what features they are going to want. However, what I’ve really come to believe over this little hiatus is that I’m wasting way too much time thinking about extended features, when in reality until people start using my software and giving me feedback I don’t really know what the customer wants, I can only think I know, even if I am a customer myself. I’ve said all this before, but this time I’m being ruthless in applying these principles.

So, I’m chucking a lot of my ideas for the future out the window, and am going to concentrate on the few features that I want now, and think others also want now (deduced from posts to forums etc). At the moment I’m the only customer I can talk to, so I’m going to satisfy my needs first, and wait for feedback before spending time on any further features.

As part of this re-focus I’ve designed a much better user interface, having some time away from the project and in particular using a few apps that I really enjoy using has made me realise that I was going down the wrong route, I was complicating the interface when I could really do a lot better with only a handful of controls. I was going to be using tabs to separate different views of the data (remember, this is primarily a reporting/data view tool), but this was a bit clunky and meant the user would need to use at least two clicks to change their view of the data, with a lot of eye movement in hunting down items to select in a newly visible tab. There are better ways to do this, there might be a slight increase in clutter in a particular control but subtle use of colour and visual separators can help the user quickly find the area they are looking for.

Anyway, tonight I’ll be back on the development box and ripping the app apart, I think I have a fair bit of work to do now, but less than I would have if I hadn’t re-focused my view of the apps future, I’ve got my confidence back and am seriously excited about getting down and dirty with the code again.

As Lachlan has also concluded, releasing earlier with a reduced feature set and improving from there with customer feedback is a very good idea.

I might not have any experience in the commercial software business yet, but in corporate and bespoke software I see this happening all the time. Release something that gives a good base to work from, based on initial customer requirements, let the customer see and work with what they have asked for. You’ll then get lots of feedback that will improve the application for the customer, which is the most important source of feature specification you can get, feedback. A tricky part in writing bespoke software is stopping the customer asking (or rather insisting on) the bells and whistles that are unlikely to be used, and that take a lot longer to develop for. The obvious answer is to quote high for these things, which inevitably leads to them being dropped from the initial requirements and pushed into a second delivery phase. What usually happens is that once the customer gets their hands on the application, even in User Acceptance Test, they see that they can work just as well without these extras, and can identify far more important improvements to take their place in a second delivery.

Again, the feedback loop is the key here, the shorter it is, the better, which just so happens to be a key principle of eXtreme Programming (XP) and most of the Agile methodologies.

I believe this is the only way to go if you want to make a sustainable software business, I might yet be proven wrong, but as long as you have a product that on initial release has just enough features to make a good portion of the potential market take interest, the feedback you get from them will be hugely important and will steer your subsequent development for quite some time.

Deciding what is a good initial feature set is however very important, it needs to be enough that you satisfy some need of your potential customers, but not so much that it takes a decade to write the software. This is obviously tricky to get right. In my product my feature set is quite skimpy in a particular area that I think I will get lots of requests for, I know I will, but I also know that it will take a lot of time to get it right (and may require some expenditure for a third party component). In the mean time, the similar feature that I think is going to be more important will be there, almost in full, and that feature is the core that will be built on and expanded in later releases. There are important features that I intend to introduce along the way that will further improve the application, some I expect to introduce before the one that may require a third party component, they all build up to give the user flexibility in this area, and ultimately many users may not even want this key feature because they can integrate other tools into their workflow that they already own and know, and can do a lot better than my app can initially. When I get the feedback, I’ll be able to decide what’s next on the list, what’s the most efficient new or improved feature that will make my existing customers happier and will maybe win new customers.

You need to think organic, grow your software slowly as your customer base grows; this is one of the primary principles and advantages of being a micro-ISV. Nurture your software, feed it, water it, and keep an eye on the leaves and fruits to determine what is needed to keep it fruit bearing for a long healthy future.

What the heck, this project is fun, I’m learning a tonne of stuff every time I get coding, every time I read some more about marketing. I’m learning loads from all the blogs and web articles that I’m reading in the area of small independent ISVs and shareware marketting. Maybe I should quit worrying and just get on with it.

The best thing about it is that it’s not really costing me a lot, there’s the initial outlay for RealBasic, which wasn’t much, then there’s the time I spend on coding and research, but that’s negated by my enjoying every minute. The biggest cost is probably the time I spend locked away in my office away from the wife, which isn’t good. But, to be honest, I’m completely addicted to computers, have been since a kid, my wife understands this and accepts it, I think. This doesn’t mean I’m allowed to go over-board though, I do occasionally get a kick up the rear for not spending enough time with my wife, although curiously it’s usually phrased as “spending too much time on the computer”, I think she’s jealous, and probably rightly so. I do spend way too much time on my computers, I recognise that. I go through phases of moderating my time, but after a while things do slip and I have to be reminded that I’ve got a life outside of computers. Is there such a thing as “Computers Anonymous”, hope not, and if there is I’m not going to join anyway, I’m enjoying coding on my project way too much!

I’ll talk about how I’m combatting the imbalances in my life in a later post (and yes, I’m aided by computers!).

Anyway, it’s Friday night, DVD, couple of nice beers and snuggle up with the Mrs on the couch night.

As mentioned earlier, I do see a wider market for my app, if I build and market it correctly I believe I can grow it to encompass other similar web apps (and there are many) that rival my current core vendor’s product. I’ve yet to decide whether this is a good idea. Should I concentrate on making it a niche product that meets a very distinct need? Opening up the app to be compatible with a number of vendor’s competing web apps may just pollute the brand weakening it. If I open up the brand in this way I’m sure to get a few extra sales, but probably at the cost of sales in the initial market. It’s an age-old quandary. If I keep the brand intact, and very focused, there’s nothing to stop me creating other versions of the app for other markets, and branding them differently I suppose. There’s a lot of talk in The 22 Immutable Laws of Branding and Marketing about just such things, their advice definitely seems to be to keep each product very focused and not to line extend. This brings me back to the naming problem; do I keep it very focused on the core vendor’s product name as it currently is? I guess from what I’ve just said the answer is yes. Maybe there isn’t the market for the other platforms anyway, maybe I should just concentrate on the one I know and believe there is a demand I can satisfy.

The only competition there potentially is for my product is the vendor itself if it adds features that negate my advantage, and some much more expensive and un-focused apps that take a lot more setting up and tweaking to get productive with. But am I deluding myself? Is there really a market here? Why has no-one else got an application that does what I’m planning to do? It’s not anything really complicated, so is it just a case that no-one can be bothered with such a small market, or do they see that there really isn’t a market at all?

Maybe I’m worrying for nothing, maybe I’m really just procrastinating. The fact is that when I do get a chance to do some real coding on this project, I really do enjoy it. I love programming in RealBasic, it’s really fun, a real blast, and a real breath of fresh air compared to my current full-time occupation. Really 🙂

One downside of my app is that it obviously needs to connect to the database directly. This could be an issue for some companies that might not want to open up the necessary ports on their server so that a little app from an unknown company can connect to one or more of their key databases that potentially have some very mission critical data in them. Although my app in its initial form is going to be read-only, how would a company know that there isn’t some malicious code in there that deletes all entries from a table? They don’t, they have to trust me and that could be a hard sell. And I’m not ruling out creating a version of the app that can update the target database if enough customers ask for it, and if the core vendor gives me the nod.

Which leads me onto another potential problem, although I hope I’ve read the core vendor correctly and it will not be an issue. What if the vendor of the web app takes offence at me trying to make some money out of providing some complimentary tools for their product? I don’t really think this is an issue as the company’s track record is good, they have other products that have gained some complimentary tools and I think I have even seen them recommend them in their forums. I believe having complimentary tools like I intend to sell generally help the core product as it creates a community around it that attracts more attention. It’s still something to think about, and I fully intend to have a little chat with the vendor in due course to sound them out, and hopefully get their blessing.

So, this last month I’ve been having some serious second thoughts about the viability of the software I’m very slowly creating.

I’ve spent a lot of time re-assessing whether there really will be a market for my product and whether there is going to be any potential growth from it into complimentary products and services. Even the name I’ve given it is looking a little shaky at the moment as it doesn’t scale to other uses, but the application could be used with multiple types of servers with a little work.

This is important stuff, and I’m still not quite sure whether it is a goer or not, so I’m going to ramble here, maybe something will come to light.

Part of the problem is that this product is an add-on for a product that is gaining features all the time, and there is quite a chance that some of my key features will be added to the main product. If this happens, then why on Earth would someone buy my product?

Ok, my product is a desktop application, this is probably a selling point for a good percentage of my potential market and is very unlikely (at the moment) to be added as an option to the core product which is at the moment browser based. However, the initial features that would actually add value to the current product could be added to it, and most likely are being added in the next major version. The whole reason for me creating this app is that users of the core product keep asking for certain features, as such the vendor would be amiss to not include them in a very near term update wouldn’t they?

I guess a big positive of my app being desktop based is that the features I can add are potentially going to be far more user friendly in execution than with a web app. I can update subsets of the displayed data as and when I need to, and manipulate it without connecting to the server far more efficiently and without any browser standards compliance issues. Simple things like re-ordering data in a list is so much easier on a desktop app than a web app, there’s no need to connect to the database, no network traffic, and no fragile JavaScript or such like to be broken by the browser.

As a consequence of being a desktop application, it’s entirely possible that I could make the app able to function in a disconnected state, this could be a bonus for some people, but I’m not sure whether it’ll be a huge benefit for the majority of potential customers. The work involved in adding this kind of functionality pretty much requires that I hold off until it becomes a regular feature request from paying customers. But first, I have to actually get some customers!