I think that customers are going to focus on the "fit and finish" of your product, not what platform it's running on. If you write it in ASP.NET, most Microsoft-based businesses will be able to run it, as well as any non-Microsoft-based businesses that use Mono.

Just make sure to test your app on both Windows Server and a couple of flavors of Linux/Mono, and each of those combined with the major database vendors (MSSQL, Oracle, MySQL, PostgreSql). If it works well with all of those "out of the box", I think you'll have a lot of happy customers.

I failed to mention that my application will also be delivered as a service, not installed on my customer's systems.

I don't think it will be dramatically more likely than losing customers because you've written it in a language other than .net and the shop is all-Windows (which is a pretty high percentage of small/medium businesses, as they haven't yet reached the point where the cost of Windows server solutions becomes a big number).

We occasionally lose customers because we don't have a Windows version, and our products are smack dab in the middle of Linux' stronghold (web servers for shared hosting).

I do think it worth noting that Fog Creek builds their apps in a meta-language that compiles to PHP and .net, for this very reason. Given that they are historically a heavily Windows software oriented shop, I think it's worth considering why they would go to so much trouble, and do something so batshit crazy as to write a whole new language, just so they could reach those non-Windows deployments.

In other words, I don't know. Launch with what you know and what you can build quickly. When you have customers, and are talking to new customers, you'll find out quickly whether you made the wrong decision...and it will be in time for a course correction. Rewriting in a new language three months in is a 1-2 month job. It'd be a setback, but not crippling...and getting started right away is better than letting analysis paralysis set in.

A meta-language approach is great for increased portability, but also requires a larger up-front effort than a single platform solution. You would need to need to define your meta-language, build the code generators and test. As you develop the application you will most likely need to evolve your meta-language toolset. Testing will also require that you test for each of the targeted environments. It's a significant increase in investment in order to capture incremental market share. I have no idea what Fog Creek's ROI is on their meta-language compared to the .Net only projects.

I've found that a lot less people care what you develop something with than whether what you developed is something they want to use.

The company that I work for and those that I have worked for in the past would never reject an application because it was written in .NET. We would only reject an application that did not fit our needs.

I think you are right to stick with what you know.

You can't please all the people all the time. Regardless of what platform you choose there always will be those who as "Why didn't you write it for Blub?" Delivering a top notch application to large market segment has a far greater potential to succeed than a lesser app to a different, possibly smaller, segment.

Your business success will come from how well you support the product and how well you respond to market feedback and implement features that are in demand. You are more likely to accomplish that goal with what you know well and are comfortable with.

Two thoughts:

1) The money they spend on a windows server to run your application on is money out of your pocket.

2) If you will support plugins like wordpress, trac, etc, you'll have an easier time creating a plugin ecosystem with open source tools.

Then again, I'm biased since I work in a linux/java/ruby shop.

I'm assuming that you plan to have your customers install the application. If your target customers are the makers of software as a service, why not sell them your software as a service?

I failed to mention that my application will also be delivered as a service, not installed on my customer's systems.