|Perl: the Markov chain saw|
Part of the issue with selling a Perl-based product is that Perl is inherently opensource. While this doesn't always mean "free as in beer", it tends to be that way, culturally.
I work for a very small company that builds and customizes a reporting web application as part of a package that another large firm sells. It's currently written in Perl, so it would be a Perl product that's sold again and again.
What's special about our product is that it's not a product, per se. It's more of a service that happens to be written in Perl. In other words, we're a consulting firm in disguise. And, frankly, that's how you're going to have to think of yourself. While you may be able to ride the gravy train of a certain product for a few years, you're not going to build your business unless you're a domain expert first and a producer second.
There's a lot of really bad programmers out there*, but it's not like they have their abilities tattooed on their foreheads. You need to have all the credentials in the world in order to be a recognized domain expert. For example, Stonehenge is a well-known Perl consulting firm. Why? Because Randal Schwartz and brian_d_foy are there! If you want to hire someone, you want to go with the best you can afford. Stonehenge has two of the TOP names in the Perl world. In other words, you have to compete with that if you want to grow your business.
Now, it's not all doom-and-gloom. You can go away from the Perl-centric idea and just build a good web-based product to market. For example, that's what Basecamp does. I bet you can't figure out what language they're using. I'll give you a hint - it's not Perl.
*: According to some estimates, the top 1% of the world's programmers are more efficient than the other 99% combined. Figuring out which side of that line you fall on is tough. But, the nice thing is that it's easy to go from one side to the other, if you're willing to devote yourself to it.
My criteria for good software: