YC Software Startups: Value and Initial Programming Language Used

We have been ripping out node bc basic backend frameworks are too small and mercurial, so breaking API changes every year on simple things like making an HTTP request has meant a lot of time not spent on our users. The ROI is often ultimately miniscule perf, and ironically, CVE fixes from such a cowboy culture. (We are also ripping out node bc current inability to work with data ecosystem well + shitshow that is build times / maintaining them.)

Frontend has been getting better. Part of that is we have largely stopped adding any dependencies and been chiseling down to react + a few components, and between them + the webpack team, focusing on the few teams we trust to respect end user code more than they value whatever feature idea that month.

I spent years on making JS better and we have built stuff to make it sing, so bittersweet business decision driven more by the unmaintainable code culture than the language (npm/node are growing up, V8 is amazing, React achieved a lot of what early framework people marched for, ... ).

EDIT 1: Part of the technical problem may be around npm semvar and in turn, the dev culture around it. Dutifully updating semvars upon breaking changes may have given a false sense of being friendly for maintenance. Major upgrades are still necessary in practice due to peer dependency requirements triggered by CVEs etc. It's ~awesome to now see breaking changes in better modules. However, having to do via searching github stinks, and horrifying how many there are. This is still a far cry from not consistently breaking everywhere, gofmt, etc.

EDIT 2: I don't blame OSS devs for hobby projects unrelated to their work and with no claims of aiming for prod ready / corp use. But as soon as we get to core node infra teams and their VC sponsors causing a bait-and-switch on infra focus, or tech leads at unicorns & bigco's doing their here today / gone tomorrow thing, etc., I get heart pain around adding any dependencies around this broken techsocial ecosystem.

Comparatively, I'm sure a chart with database swapped out for language would show a huge over-representation of NoSQL products like Mongo and Couchbase. Yet for the overwhelming majority of projects the right answer is just use a solid SQL product like Postgres.

Again, for SV hyper-growth startups the calculus is different. Mongo has tons of downsides and pitfalls. But the one thing it has going for it is, you can get started fast without having to think about it. Just throw shit in a giant nested key-val map and pull it out later. You don't have to design schemas or provision ahead of time. Change the JSON on the fly, and if you hit performance issues, just throw more hardware at it. Move fast and break things.

For 99% of projects that kind of attitude comes back to bite you in the ass. For every hour that you save today, you'll end up spending ten hours in a year or so from now when you're eventually forced to detangle a crusty sloppy mess.

But for a unicorn-aspiring SV startup, that tradeoff works. Almost any startup would gladly spend a hundred man-hours in a year or two, to get back one man hour today. And that works, because the growth rates are astronomical. In a few years, you'll hopefully be a billion-dollar unicorn with tons of resources to throw at the minefield of quick and dirty technical decisions you made at the seed stage. (More realistically, you simply won't be around anymore, at which point the pitfalls in waiting also don't matter.)

The point is don't necessarily pay too much attention to the decisions made by YC startups. This is true even for regular startups with more prosaic aspirations. (Some of us are more than happy to own $10 million companies, and aren't aiming for billionaire or bust.) If your business model is rooted in 1000% hyper-growth rates, that encourages many tradeoffs that are otherwise deeply pathological.

We have used Postgres from day 1 in March and are now 1200 people. Managing growth with a JSON blob sounds absolutely insane.

You need _more_ guarantees, not fewer.