Ask HN: Would a .Net back-end put off potential acquisitors?

> So in your opinion should I bite the bullet or go with what I know?

Yes.

As much as I don't like the .NET stack myself, you should go with what you know, unless you're specifically looking to learn something new. There's enough risk in starting up as it is without burdening yourself with learning an entirely new stack.

Is Mono viable for server these days?

I wouldn't think so. Your tech stack is going to be one of the last things they care about. Besides, .Net is very well established so if anything they'll take comfort in that.

It's all about the product and users.

Thinking about potential problems with an exit before you've even started building something is frankly ridiculous. Just start. What anyone might buy in a few years time if you're successful will be very different to what you build now because you will learn things about what the customer wants along the way. Whether that's shifting to a more appropriate language is something that only time will tell.

They won't care about your tech stack if you have the users. If a large company like Google acquires you they'll just eventually recreate the entire site in their preferred language and preferred frameworks anyways.

If you have a great product that you can get live quickly and works then it won't matter if you even write it in COBOL (don't write it in COBOL though) - ASP.Net & SQl Server (even the free version) also work very well together and have great performance.

There are of course licensing costs if you run on Windows and don't use MONO but these shouldn't really be an issue in comparison to all your other costs

Also there are a lot of ASP.Net/C# developers around (just look at odesk) which will help you build your team faster (unlike Ruby or Scala developers, which are great languages, just harder to recruit and also attract higher wages).

My advice... build a proof on concept as quickly as possible - if .net is your thing then use that vs. wasting time learning something else. The chances are that your concept may need to be reworked so why waste time...

Good luck!

Most likely this is major overthinking and your energy is better spent back here in the present day on first-order concerns like making people receptive to the actual product!

Write your product in the language that you know best and is suitable (which is .Net).

You don't want to be struggling to show hello world on a page with an unknown framework compared to building your actual product with a language you know.

I've written many projects in PHP and .Net.

My latest startup is all .Net and the right choice.

The is a possibility that some MS hater would refuse to buy on that basis or made it an excuse to buy someone else. It's close to zero though.

Just as a data point: http://meta.stackexchange.com/questions/10369/which-tools-an... Web Framework ASP.NET MVC 5 with MiniProfiler

Ship the product and get traction. The back end doesn't matter unless it hurts you achieving these two goals. Maybe other backends will help you achieve your intended results? That is the only real question that matters. Traction is hard to achieve and is paramount.

No, but a discussion around the tech you're using might.

It's about making something people want -- even if you have to do it using clipboards, rubber bands, and duct tape. If they want it, you can figure out the tech later. That's the easy part. The hard part is connecting with people you can help.

I've been in this situation a couple of times before.

It won't make a blind bit of difference initially but if you expand, so will tooling and deployment costs and investors don't like that. Anything that takes off the bottom line is a problem. Microsoft licensing, particularly dev tools and SQL is incredibly expensive and an order of magnitude more expensive on deployment and diagnostic time than anything else.

We're like that now. Our SQL licensing is shaping our architecture not on technical merit but avoiding core license costs. That is beyond bad but we can't justify a £200k spend on licenses and kit to get rid of 2008R2.

Inevitably bits of Python are now appearing around the edges of the product and trying to stab the core. There are a couple of postgresql machines doing ancillary work. All the staff are slowly moving their operational task over because there isn't a purchase process.

This is the price of success though :)

Edit: just to add that the last two companies I worked for are Python/java/postgres houses now after being end to end MS outfits. The staff change over the lifecycle of a product. You can afford better people after time and better people seem to prefer to use other platforms even if they market themselves as .Net people.

Edit 2: also once you're locked in, volume licensing looks cost efficient. Then after a couple of yeara you get a call from the sales guys at MS who want to do a 'soft audit' (which it says they can so in the VL agreement). Then battle commences between MS, yourselves and the disty who handles your VL over how much you owe. This usually starts at £150k-ish for an SME and your ops team will be down for days whilst they work that down. Our liability was less than £10k which is within the VL safe zone but other companies are less lucky. Also the VL settlement says you can't discuss it but fuck them - the company this was against is dissolved.

Actually I look at my post and I couldn't possibly recommend it. If we'd started differently we could afford to be employ and sponsor postgres core team staff for example and gave second to none support and a positive impact on the community. Instead, pockets are lined elsewhere.

  Internal use licenses are for use in a production environment for general internal
  business purposes and not for any type of commercial purpose. For example, installing
  the Windows Server operating system and Microsoft Exchange Server to set up an email
  system that you can use to send business-related email is acceptable. However,
  production use for external commercial purposes, such as hosting a commercial website,
  is outside the scope of these rights. 

  Customer demonstration licenses can be used for demonstration purposes only by partners.
  Sales and marketing employees of the organization can use this software to showcase
  products to your customers, but demonstration products cannot be installed on customer
  hardware or infrastructure and must be used with partner supervision.

  Internal-training licenses can be used for training internal employees only. These
  licenses cannot be used for customer training or for any commercial purpose.

  MSDN subscriptions allow designated employees of your organization to use the available
  software for the design, development, testing, and demonstration phases of application
  development.

    Can you install JIRA on that copy of windows 2008 server R2 and access it via VPN?

    Can you run your staging site on it for demonstration purposes?

I don't think it matters. Just look at some of Microsoft's buys: Yammer (Java), Skype (not sure but not .NET), Hotmail (FreeBSD), etc. Traction is the key.

Sign up for Bizspark and you don't have to worry about licensing for 3? years.

It doesn't matter at all. In general investors have no clue about coding.

If you are technical founder then go with what you know. No questions here. Regarding licensing, you will anyway then run on Azure so licensing costs might not be so terrible.

If you not a technical founder and your goal is being acquired than technology does matter. For example, if you are in the market where, Oracle or Salesforce are potential acquirers then do not use .Net. Be more SQL / Java oriented.

And if your end-goal is getting revenue and profit, then it does not matter.

You should never forget your licensing costs if you ever need to scale to "internet scale". However, it's more important to get a product out the door than to have a hugely scalable thing. If .Net is the best tool for your team to do it, then use it and work out the scalability issues later (you may consider keeping an eye on migration costs - it's easier to add app servers than to scale a RDBMS) and always having a plan on how do you turn what you have into what you'll need. You may even be very successful and not need to change too much: the Stack Exchange folks run a lot of their infrastructure on Windows.

I make my PoCs with Python on Google's App Engine. It's zero management and any individual idea is far more likely to fail than to be an overwhelming success, so it's reasonable to think about costs if and when the idea gains traction.

Another thing you should consider is how the stack you pick will affect your ability to hire great talent in your region.

Note: I really hate .Net (and Windows) but these are not decision one makes based on passion.

I have experience with this. We started a company based on a product written in C#, and were acquired by a company by a company whose product was predominantly written in Java. It was never really a concern during the acquisition.

The software world is so diverse now that you could never predict who would be interested. If you ended up writing your product in a JVM language, you may end up with a Ruby suitor, etc. It's always best to just use the tool that you'll be most productive with, and will result in the best product.

I think it wouldn't hurt and if anything would allow you to find developers easier than if you did it in Rails, Node.js, Scala, or Go.

There are a ton of developers doing .NET or Java EE for large companies everywhere. Having that talent pool available is more convenient than having to recruit in more obscure platforms.

My short answer is, go with what you know, it's better to have a solid working product than a flakey pile of learner spaghetti.

I'm a .net dude at a startup though and to be fair long term costs should be factored in, but can be mitigated. For one BizSpark is an absolute must to get started, and once you graduate there are the Action Packed for a few hundred dollars a year.

I would however suggest you look rather at using oss where possible even from . Net. We have used MySQL, Mongodb and redis on Linux because it keeps scaling costs down, and to be frank they' re better supported on the platform.

We also leverage BitBucket and TeamCity rather than TFS for cost reasons.

Having said that both Azure and AWS have fairly scalable windows and SQL hosting services.

.NET is an advantage not a disadvantage. HN can be utterly bizarre sometimes.

No investor cares about what language your product is written in. No client does either.

Use what gets the job done, think a little about scalability and modularity from the start. Don't optimise until you have plenty of data. Over thinking things like this will prevent you from the initial release.

If it works, great. But like all projects, you might have to throw away significant portions of your system away to grow. Being too tied to one specific technology will defeat you.

Try to find product/ market fit as quickly as possible. My personal rule of thumb is to find 10 paying customers before you can declare product/market fit.

The stack really doesn't matter and should be least of your concerns at this stage. I used to work for company whose stack was .NET. They got acquired a year back for 1.6 B dollars.

We're a company with a .net stack that is being acquired right now.

It didn't come up until their senior engineer said we should rewrite everything in Angular.js and Java. The tech management guys quickly said, "Sure, maybe, but for the foreseeable future, we will SSO between the two systems and plan for deeper integration later."

Hands on engineers care a lot about tech choices and sometimes have actual good reasons. At the business level, nobody cares as long as you can meet the business need.