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!