By Bob Walsh, Safari Software, Inc.
Over at The Business of Software forum, Jackson asked today,
“But the problem is – how to know what kind of (web or desktop) app to build. How do you detect the trend that will be big, while the trend is still in its infancy”?
Of the 68 things you have to do to be a successful micro-ISV, figuring out what kind of app you”re going to build is first and foremost. Get this right, a few years of sweat, toil and work may just make you the next Google Guy; get it wrong and all that effort will be wasted barking up the wrong tree.
Now if I had the absolute right, one-size-fits-all, ironclad answer to this I”d package it up, sell it, and sail off to some very nice tropical isle. No such luck. But I can suggest three pointers, based on the research I did for my micro-ISV book, and a bit more rumination since it came out in January to get you started.
Get off the Hype Cycle.
Teenagers have cloths and cell phones, programmers have the latest and greatest programming technology. They share one thing in common: the Hype Cycle. The Gartner Group defined this 12 years ago as the cycle new technologies go through, whether they”re as big as P2P VoIP or as small as Ruby on Rails.
They cycle starts with a Technology Trigger, such as Jesse James Garrett”s seminal post on Ajax. Then it moves to the Peak of Inflated Expectations (where we are now) when everybody who is anybody or wants to be anybody is doing it and getting VC money to do it. Next is the Trough of Disillusionment, when the shine is off the apple, the VC money runs away and people wonder what all the fuss was about. Finally, maybe, the technology makes it to the Slope of Enlightenment and perhaps the Plateau of Productivity where real benefits, revenue and results accrue.

Gartner Hype Cycle

Over 25 years, I”ve seen a multitude of technologies ride the Garner Hype Cycle (more info here and here). The Hype Cycle is not your friend if you”re starting or building a micro-ISV:

  • Hype Cycles and VC money were made for each other, hence the VC saying, “fund 20, pray for 2”. Unless you get very lucky, or can program very fast, your odds of catching a Hype Cycle at the very beginning are marginal.
  • If you miss the wave, you are going to go down. “Me too!” is not a revenue strategy for micro-ISVs ” we usually don”t have OPM (Other People”s Money) to burn.
  • Micro-ISVs have customers ” or hope to. Customers have problems they hope to have fixed. If the technology being hyped can”t be used to fix a real problem, it”s not going to fuel your micro-ISV.

Don”t write a product for programmers.
For most programmers who decide to go micro-ISV, the first impulse is to write an app or tool or library for other programmers. Very common, very human, very wrong. Now don”t get me wrong, I love new programming tools and stuff as much as the next programmer. And if you”ve got a genuine product that will solve one of my many unmet needs, I”m going to poke around Google until I find you.
But as a micro-ISV market, programmers suck. Unless you”re product does something I really am impressed with, the typical programmer is going to puff up their chest and huff, “I could code that in an afternoon!” as they click off your web page. What”s more, the programmer market is from a marketing point of view dozens of tiny little programming language enclaves, each jealous of the others.
Finally, a programming tool is not the same as a way to solve a specific problem that people online with money actually have, it”s just a potential: it will be a very hard sell to convince IT managers or individual programmers that they need another tool unless they just so happen to need that particular tool at that particular time.
Pick part of the Long Tail, and solve it well.
One of the few key advantages micro-ISVs have over existing companies is the opportunity to look at a problem and solve it better and deeper. The world abounds with problems solved poorly or not at all.
Think about any company you”ve ever worked work and how they used Microsoft Excel as the application to solve all sorts of specific small business problems. Why? Because until very recently it was just not economically feasible to develop, market and support a solution to a business or consumer information problem that only a few people here and there had.
With a billion people using the Internet, and the ability to create an instant market with the right search terms, there are tens of thousands of problems that can be solved lucratively now by micro-ISVs. It”s called the Long Tail, and if you don”t know about it, it”s time you get read in. The Long Tail and micro-ISVs were made for each other.
Picking your micro-ISV”s market and defining your first application – be it for the web or desktop or mobile or PDA – is not easy, but it is critical. I”ll have more to say down the road re finding problems worth solving, but for now, avoiding the Hype Cycle, getting knowledgeable about the Long Tail and not writing a programmer product will get you off to a good start.
Bob Walsh is the author of Micro-ISV: From Vision to Reality, hosts of this site, runs a micro-ISV and fixates on all things related to Getting Things done over at


  1. Nice post, Bob.
    “Don”t write a product for programmers” is great advice, there’s a whole world of non-programmers out there who really need software that solves their problems. The big challenge for us is to find non-programmer problems we know well enough to really solve.

  2. Another reason not to write a product for programmers: There’s a good chance that a comparable open-source product already exists. Many programmers automatically pick the open-source choice, if only because they imagine themselves fixing bugs and adding features. Few do, of course, but a lot of folks seem to like the warm fuzzy feeling of knowing they could. (Beyond that, in many cases the open-source product is flat-out better than its proprietary competition, anyway.)
    But the landscape changes completely when you look at nonprogrammers. Few open-source products have UIs good enough for nonprogrammers to use. And access to source doesn’t provide (direct) value to nonprogrammers. So most open-source products only have the advantage of price, and that can be overcome with usability, features, and support.

  3. Pingback: BackupBrain: My MicroISV Venture

  4. Other than just complimenting you on your impeccable taste in software, I also wanted to chime in with a little story.
    When I was in college I had a roommate who was a journalism major. He headed off one evening to hear a campus speech to be given by one of the editors of the New York Times. It was an event he’d been looking forward to for a while. But later that night, he came back looking a little dejected.
    As it turned out, after the speech the editor had opened the floor for a Q&A session. One of the students asked what the editor thought a journalism student should to get a great start in the profession. His answer was, “Change your major.”
    His point was that, although journalism courses give you the tools to write for the news industry, it’s the deeper knowledge about a subject that makes the writing worth reading.
    While I’m not suggesting that no one should major in computer science, I do think it is important to gain domain knowledge in other areas. And while some startups have been very successful with tech-oriented products, I think the market is more crowded by its very nature.
    Just my $0.02.

Write A Comment