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

18 points by stasel 10 years ago | 35 comments

I'm a Linux/Mac guy that loves node.js but my friend is more familiar with C# / Microsoft technologies. Me and my friend are building a nice web app with Angular js and we cannot agree on the server side technology yet. He wants our server to be written in C# and MS SQL server. I feel way more conferrable using node.js with Postrgres and Linux servers. Each of us tried other's technology stack and every time one of us had difficulties developing on the other's preferred technology. What should we do in order to help us to solve this problem?

smt88 10 years ago |

Here are my thoughts, in no particular order.

- 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.

keefe 10 years ago | |

Using a single language on the front and back is a very nice plus, especially with ecmascript 6 support. My current job is doing that and it makes it much easier to break off features without having to get the server guy (me) involved. I personally feel like there is more javascript out there as well, so it's points for staffing.

C# I think is probably better documented, with fewer hair pulling bugs (I will frequently have to read code in a library to understand how exactly to use it in nodejs) and I'm very much missing a standard threading system, but I think early on it's more important to go fast so I would vote full stack JS over JS + .NET

skylark 10 years ago | |

I feel like if you use a lightweight node/express setup, you feel really productive because you're spending a lot of time coding, but you're actually far less productive than someone who uses an actual full fledged server side development framework (Rails/Django). For toy projects I do enjoy node, but if I was throwing myself into a startup, I'd use Rails without hesitation.

t-rav 10 years ago |

Pick a stack and go, your just wasting time and effort that is not focused on your value prop.

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.

ac2u 10 years ago |

I'm assuming you're already past the stage where you've verified the problem you're solving is worth solving with technology, otherwise you're wasting time.

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.

rabidonrails 10 years ago | |

ac2u FTW! Follow these steps:

-What you can work on fastest

Then:

-available hiring pool

-finally things like licensing

maybeok 10 years ago |

For the DB use postgres to save licensing costs. I would be more adamant about the DB decision than the language. It's nice to be able to deploy unlimited postgres DBs on as many servers as you need without breaking the bank.

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.

GFischer 10 years ago | |

To be fair, they could apply to BizSpark and the licensing and hosting costs would be moot for 3 years (and it has lots of great benefits):

https://www.microsoft.com/bizspark

Btw, you can host Node.js apps on Azure if you like (I do), and a Linux stack if that's your thing, so it makes sense to apply to BizSpark even if you're not going the C# route.

dagw 10 years ago |

Compromise and go with RethinkDB and F# on FreeBSD? This way no one gets what they want.

eswat 10 years ago |

I think you need to give one of you of the role of calling these shots and trust the other to make the right tech decisions so you don’t burn energy and time on trivialities like these.

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.

onion2k 10 years ago |

Flip a coin. Seriously. Moving forwards is far more important than being "right". If it turns out you made the wrong decision you can always fix the code later. All the hard stuff (data models, business logic, etc) is portable between languages.

such_a_casual 10 years ago | |

"Flip a fucking coin." is exactly what I was going to say. Clearly the decision is influenced way too heavily by each of your pasts rather than on the merit of the technology (either will do exactly what you need it to do). So just flip a fucking coin, or come up with a more interesting way to settle these kinds of trivial pursuits.

floppydisk 10 years ago |

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.

timjahn 10 years ago |

It doesn't matter.

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.

kogir 10 years ago |

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.

csomar 10 years ago |

I'm not sure if my advice is useful. I believe in leadership. Pick a leader, and there you have your problems solved.

runT1ME 10 years ago |

as smt88 said, TypeScript sounds like the obvious choice. He probably enjoys the type safety aspect of C# along with Visual Studio (or whatever IDE he uses). You appreciate the fact that the same code on the server runs on the client. You could nail both of these using TypeScript.

herbst 10 years ago |

Sincerly if you both are stuck on your platform and both want to work on this it wont work. Altough your friends choice sounds terrible you probably should just stop beeing friends?

senjindarashiva 10 years ago |

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.

lovelearning 10 years ago |

Perhaps evaluate the financial aspect of each stack, and compare.

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

dagw 10 years ago | |

Microsoft gives startups free software licenses for the first 3 years and free/discounted access to Windows Servers on Azure. After 3 years you're almost certainly either making so much or so little money the extra license cost won't be a significant factor.

EvanPlaice 10 years ago | | |

The first hit's always free.

edimaudo 10 years ago |

Ahh! yes decision making in startups, fun times. Well in this case it may be wise to develop a decision making process or framework. You can choose from one of these listed here https://www.mindtools.com/pages/main/newMN_TED.htm

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.

quintes 10 years ago |

Things will only get more difficult. pick the stack and move on.

Raed667 10 years ago |

Pick something that MOST of the people doing the actual devs are comfortable working with. You really don't want your team's time spent on learning new things.

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.

wturner 10 years ago |

Decide who is more comfortable learning new things....and go with the other persons stack.

lastofus 10 years ago |

Perhaps you could split development along front-end/backend lines. One dev uses whatever backend stack they want, and the other does all the HTML/CSS/JS.

debacle 10 years ago |

Don't use MS SQL server. It has serious issues with locking at scale that you can never get around. Apart from that, just make a choice and run with it.

GFischer 10 years ago | |

At what kind of scale? I don't think any web application should have problems unless the queries are very badly designed.

I've worked with MS SQL for 10+ years (at financial institutions) with no problems. Oracle might be a tad better, but it's also pricier. No idea about Postgre (I've heard it's good), but what you mention shouldn't be a good reason to dismiss MS SQL.

cakes 10 years ago | | |

I would also like to know at what scale as I've used MSSQL for several years and only badly designed queries/tables caused locking issues.

The real _problem_ (which BizSpark can resolve short-term) seems like it would be licensing.

richev 10 years ago | |

SQL Server scales fine...just ask Stack Exchange. http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-s...

vskarine 10 years ago |

Tough situation. In my exoerience, best way to resolve this is to try each stack for couple of days.

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.

rajacombinator 10 years ago |

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.

matthewmacleod 10 years ago | |

This has to rank as some of the worst advice I've ever read. I don't use the Microsoft stack, but the idea that a preference for it means that one doesn't have "what it takes to build a fast moving web startup" is fucking ludicrous.

elchief 10 years ago |

If you need enterprisey features like record versioning, auditing, optimistic concurrency, good authn/authz then use .NET over Node.js

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.