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

On the side note, I highly recommend to try Meteor (www.meteor.com). I was in the same spot a year and a half ago and when we tried Meteor, we didnt know anything about Node but Meteor was so simple that we just went with it and never looked back.

Use Node. C# is too inflexible and MS SQL Server is always the wrong decision unless a client is dictating it. I spent 5 years using SQL Server, and when I discovered PostgreSQL seven years ago, it was like a gift from heaven.

Node with PostgreSQL gives you NoSQL and structured SQL facilities. Your friend will pick up node quickly if he just stops thinking in C# ways.

Designing a web service on Node will be 3x to 4x faster than in C#, and as a startup, time to minimum viable product (MVP) must be your primary concern. If, after that, he decides to try and write it on his own and prove you wrong, so be it...

Cheers and good luck!

- Don't work with a friend on a startup. You are very unlikely to be friends afterward. If you can't easily compromise on something as unimportant as your stack, you're going to disagree on way more important things. Why do you need two devs anyway?

- Two things that kills startups are analysis paralysis (always trying to make the perfect choice = wasting lots of time) and being afraid to leave your comfort zone. Both of you should be willing to use the other person's stack because it will end this pointless argument and also help you learn something new (and possibly something you like even better than what you're using now).

- If you're using Angular, you have an objective reason to slightly prefer Node: it allows you to use a single language on the front and back ends.

- One possible compromise would be to use TypeScript, which was created by the same guy who created C#, so it shares lots of the same philosophy. TypeScript is also the native language of Angular now, so you can use it on the front and back ends.

- Another possible compromise would be for one of you to work on the back end only, and the other to work on the front end only.

Strictly pair program the implementation to facilitate quick knowledge transfer of the tech stack.

In the early stages, it is about finding a minimal solution to fit your value prop so you can get people to engage with it and validate your assumptions. This requires more thinking than code. Pairing the implementation will not only allow tech knowledge transfer, it will facilitate those important idea discussions that need to happen too.

I suspect C# /.NET / MSSQL / Windows servers will be higher. In addition to server costs, someone has to pay for those software licenses too.

Just do your product.

If a stack shoes some limits when scaling or anything else along the way and if your startup is still viable, then you can plan a migration with all what you learned to back your tech choice.

In the future you may have ancillary services/apps better off using a separate DB for performance. DB licensing costs will influence your design decisions so remove those costs from the equation.

C# is fine though (even on linux) and will give you reasonable performance, likely better than node.js is most cases.

With that said, you need to divide responsibility. Either a 'CTO' role that has the decision to base the stack in his/her choice, or divide the tech up frontend/backend and give one person authority over each.

When it comes to tech decisions, look at what you can work on fastest, secondary considerations can then be things such as your immediately available hiring pool, and what would gel easier with those people, and finally things like licensing.

As developers we think picking a tech stack is an immensely important decision for the foundation of your company. It isn’t. As developers you should be competent enough to pick up the slack and learn new tech as needed quickly, and leave the extra cycles to pick up things that you suck at but will need to figure out: customer services, business model, etc.

Echoing what other commenters have said, if you’re already running into problems about decision making then it’s likely to get worse. I also think you’re optimizing for developer happiness way too early.

Furthermore, it may be worthwhile learning each other favorite stack as you could pick up new skills. Could be a bonding experience as well. Just my two cents.

Personally I'd go with a universal React.js on Express (snappy SPA for users, crawlable server-generated html for googlebot, with one codebase) talking to a .NET REST API.

Then later you can use React Native for mobile and the same REST API. Or an Electron.js desktop app talking to same API.

PostgreSQL matches MS SQL Server in most regards, but MS SQL Server kills it for text search, but PostgreSQL does row security, and is, you know, free.

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.

Focus on validating the problem first. Get people to pay you to solve that problem and once you have people begging you for the solution, then figure out something to build.

I've seen (and experienced myself) this mistake too many times. The tech stack does not matter AT ALL.

All that matters is that you're solving a problem for the people that will pay you. Don't spend 3 months perfecting the ideal tech stack and then realizing you have nothing to use it for.