Ask HN: My friend and I cannot agree on our server side stack for our startup

Damn good advice.

Your idea isn't yet working. It's not guaranteed anyone will want what you build. Figure out realistically which will get you to MVP faster, and use that. Chances are there may even be enough work to keep you both busy without overlapping.

Then, if your idea works out, you're going to learn a lot and gradually replace all the code anyway. Wait to decide then. This is the one to throw away.

1) It doesn't matter ... 2) but seriously, MS stack? I would have serious doubts about whether your friend has what it takes to build a fast moving web startup. At the very least it will limit your ability going forward to hire great web devs, almost none of which want to work with MS products. Best bet, drop your friend, get a sales/marketing guy to be your cofounder.

Personaly i'd go with C# or mono but possibly not MS SQL which would allow you to work in both a linux and a windows environment. The main reason for this would be stability and documentation. The C# language is both well documented and has good standard libraries while my impression of node is that it is an undocumented maze of mostly fairly new microlibraries. I also belive that learning to build good C# code is a lot easier than learning to build good node code.

A little bit of tough love:

You're going about this the wrong way. Build from the problem down to the tech stack, not the tech stack up to the problem. Here are some questions I'd ask in the following order:

1) What is the problem we are trying to solve?

2) At a BUSINESS LEVEL what is our solution? Not we route records through this $DATABASE and $CRUNCH_THEM, but "we enable users to solve $PROBLEM by $GENERAL_SOLUTION_DESCRIPTION"

3) What makes us different from other solutions to $PROBLEM or why is our approach more unique than what currently exists, at the business level? Better idea, better execution, what?

4) What is the market for $SOLUTION to $PROBLEM? How do we know this? How do we sell it?

5) What kind of processing do we need to do? Any serious custom crunching or are we interfacing with a database and moving data back and forth? Can we plug into existing services and leverage them rather than writing our own? i.e. AWS/Azure?

6) What is the best way to deliver this solution to the end user? Mobile? Desktop App? Web App? Some combination of the above? Why?

7) Given $SOLUTION(S) and $CRUNCH needs what's maximizes our chances for success by minimizing the number of moving parts in terms of tech stack? Do we need to do a web app + mobile with limited crunching backend? Do we need a lot of heavy server side crunching with parallelism/concurrency and a robust object model?

Let the problem space guide you to the solution rather than starting from a solution and working up to the problem. It'll save you some technical headaches later.