interesting site for microisvs
http://www.smallbusinessbranding.com/
Also, it's a good example of how linking gets you recognized. I found http://www.smallbusinessbranding.com/ because Michael linked to my Starting a MicroISV post
http://www.smallbusinessbranding.com/
Also, it's a good example of how linking gets you recognized. I found http://www.smallbusinessbranding.com/ because Michael linked to my Starting a MicroISV post
Sometimes it's important when your building software to leave features out. Actually I think it's always important, especially when you're a programmer and some of those features are in the spec as much for your own technical gratification as for customer needs. In those scenarios it's good to take a very close look at your feature set and make sure what's there needs to be there.
I did alot of that soul searching before I started HelpSpot and thought I had all the pork out of the spec, but I was wrong. So I thought I'd document the process I went through in deciding to remove a major feature from HelpSpot for the V1 release.
The feature I decided to remove from HelpSpot a month or so ago was web services access. This was a very tough decision for me because this was one of the core items I wanted to have in HelpSpot right from the very beginning. There was 4 major components to my decision.
1. Nobody wants it
Well this of course was a big one. As HelpSpot has gotten closer to completion I've been in touch with many potential customers. While I had all kinds of great ideas for the web services features it turns out that this isn't something most people procuring help desk software care about!
There's a few reasons for this. Mostly it's because the help desk folks in most organizations have no control over integrating a web services feature into their companies applications, intranets, etc. It's something that may be possible over time, but it's not controlled by them so it's not part of the criteria they're using to pick a product.
2. V1 Web services were lame
Because of the many time constraints (programming, testing) with launching the V1 of HelpSpot the web services integration was going to be limited. So you'd be able to do basic stuff like add a request. While useful, one of HelpSpots other features already trumps this. The email integration system accepts tokens within emails to automatically set HelpSpot fields.
So as a programmer for the client company I had a choice of adding an XML-RPC library to my applications and then messing around with making calls or if I want to accept requests from within the app I could just generate an email and append a few tokens to pass the same extra information to HelpSpot. I know which I'd use.
3. Waiting creates a better argument
If I'm going to convince help desk staff that they should go to their IT departments and get them to integrate HelpSpot web services inside of company systems then HelpSpot better have a convincing reason to do it. No IT department around is going to lift a finger unless there is some obvious upside to doing all the integration work. By waiting to release web service in a future version (1.5 or 2.0 - still not sure) I can create the more complete framework I originally envisioned. One that will allow companies to completely push management of requests out into their intranets and applications if they want to.
4. It doesn't create a competitive disadvantage
A big reason I wanted to do web services was because very few other help desk software packages do. So the upside is that even if HelpSpot doesn't have it right away the competition still doesn't have it. Also it's unlikely that they'll be getting it anytime soon since many are network based apps or desktop based apps or apps that were created without web services in mind. If you ever tried adding web services to an app not designed for it you know that this can be very hard to do.
So we'll see if this is a good decision. Of course now that I've wrote this up I'll probably get a bunch of email from people who were looking forward to using the web services api, but that's how these things go :-)
Went to see it last night, good stuff. Overall very funny with a few scenes that actually had me in tears. You will have to be into this type of comedy so if you like Meet the Parents and Zoolander you'll like this.
Another good one from Christopher Hawkins. He doesn't post often, but when he does they're usually good. I agree with all of it. I must admit though that I don't dress up as often as I probably should. I think it might be easier in the winter, but right now shorts are just to tempting. They're nice shorts though!
Update:
I forgot to disagree with him on one point. When it comes to buying your equipment I don't think you should get "good" or even above average. Get the very best. When you're on the computer 8-14 hours a day you don't want to have to wait for things to load or worry about not having Photoshop and BBEdit open at the same time. Don't forget to get 2 monitors as well. In the end it's not that much more, you'll be much happier and you can deduct it!
Interesting ideas on how to manage your email.
This is a question I don't think I've ever seen discussed before amongst all the MicroISV people, forums, things I follow. Perhaps it's because we tend not to think that way. Well before I get ahead of myself let me frame the question a bit.
When beginning to plan for a version 1.0 there are all kinds of things to consider from system requirements to feature sets to functional specs and more. As things progress more time is spent thinking about post launch items such as marketing, advertising, and of course pricing. Traditional views on pricing seem to focus on what value your software creates for the person or organization buying it, what the competition charges, product positioning and so on. So what I really want to know is should the future of your software be part of the pricing equation? Should features which are not in version 1, but will be in version 2 be at least partially priced for in version 1? What about features which will be in V2, but are currently unknown because they have not been thought of yet! Should they be given some value since you do know they will exist.
I don't know the right answer, but my take is that V1 pricing should take into account features of V2. When a customer purchases your software I don't look at it as them purchasing this version. Instead I see it as a commitment they're making to you and you to them. The customer wants to stay with your product. Few people go into a software purchase planning on switching to another solution in a year or two.
So if that's the case it means there's a responsibility on your part to create future versions with enhanced features and so on. And if viewed as a continuum instead of a one time event it seems logical that the pricing of V1 should reflect some of the effort that will go into V2, V3 and so on.
What do you think?
HelpSpot is using a lesser known LGPL template library called PHP Savant for all the portal aspects of the system. So far I'm really liking it. It's so so so much better than Smarty which is so heavy and complicated. Savant is light, but provides important features right where you need them. I'm planning on writing up a good size article on how I implemented everything down the road when I have some time, but here's a little taste.
One of my infinite concerns was that having a fully customizable template system was great for integrating HelpSpot into customers websites, but leads to trouble during upgrades because if they've modified the default template and overwrite those files, their changes will be lost. There are some more and less painful ways to deal with this, but luckily Smarty has a great system built in.
All the templates are in a folder /helpspot/templates, these are helpspots default set.
To use a custom version of any of them simply copy the file into /custom_templates and customize it away. Savant lets you set the include paths so that it can check the custom folder first then if it doesn't find the file it goes to the default. Since HelpSpot will always ship with the /custom_templates folder empty there's no chance of users losing hours of hard work.
Another great aspect of PHP Savant is that it's all PHP, no trimmed down template markup "for designers". Anyone who can figure out a Smarty IF statement can figure out a PHP one, at least that's my thinking and having the PHP right in there makes it much more transparent what's going on to those editing the templates.
Eric has opened his new MicroISV for biz. Interesting, it's a website editor which is basically built to help your SEO by tracking your keyword density. Good luck Eric! (Where's the Mac version? :-))
Russell does a nice write-up of the web capabilities of the PSP. Man that looks great. I think that could really be the killer combo. Everyones been looking towards cellphones with web access as the future, but perhaps its this. I mean it makes some sense.
I'm already trained that a phone should be small so when you see these ones with huge screens to make the web usable it just doesn't feel "phonish". Phones with small screens are worthless for the web. Now this is the total opposite. I've been trained that gaming systems are big and require a TV and so on. Now here's this little fellow with all the power of a big game machine plus a big screen which makes the web useable.
I think I might have to get one of these for "testing" purposes :-)
On of the guys from Laszlo Systems chimes in on our discussion.