Since I'm looking for work, let me tell you what I look for in a project. I don't look too hard at the languages, platform, or libraries being used; I know the most important ones and can learn their relatives and competitors without too much effort.
What I want to know about a start-up is this: do you have a secret sauce, and do you know how long the schlep will be?
Every start-up I've ever worked at that had any success had some kind of secret sauce. That's the core of their product. Isilon had distributed dynamic RAID years before anyone else; Spiral Genetics had a map/reduce solution to solving the human genome; Splunk understood time-series databases; Young Alfred understood the complexity of carrier/underwriter requirements for home insurance. Each of these were, at their time, industry-changing technologies, and their complexity and intricacy required a front-end that would allow their users, being they sysadmins, research scientists, or security professionals, to get the answers they needed in the shortest time and with the fewest "WTF?" moments possible.
Providing that front-end is and always has been my job. It's what I do. If you need a back-end that meets those needs, I can probably write that as well. I've done it several times, bootstrapped at least one $100million IPO, got a patent, saved a business.
The schlep is the amount of effort it's going to take to get there. The schlep is "turning those ~400 questions about your home and past history into a legal insurance contract." The schlep is "turning the output of a time-series database into visible trends and actionable events." The schlep is "correlating the output of a gene sequencer with all the available literature in the world."
The schlep is about finding the images, icons, graphs, charts, and text that will help the customer understand the problem without wasting their time. The schlep is about testing the hell out of the product to make sure that all the sharp edges have been covered.
Everything else is, literally, everything else. Your code repository, your build system, your deployment system. The languages you choose for performance, queries, UI, scripting, and shell. Your library and platform, how you do code reviews, how you package your software, what containerization and scale-out solutions you've chosen.
These are the things every developer should already know, if not in concrete terms, at least in the abstract. Moving from React to Angular should be a few days' learning. Moving from AWS to Azure will require a personal cheat-sheet of "If you want to do X, here's how it's done in Azure."
When interviewing for a company, you shouldn't have any trouble finding out if the development environment is one you're comfortable with already, or comfortable learning. You probably can't get a strong feeling for the "values" and "culture," but those are nebulous excuses used to exclude older developers, queerer developers, femme developers, darker-skinned developers, and not much else.
You want to know if they have a secret sauce, and if they're already deep into the schlep. Because if they are, they have a chance at survival. Not a great chance, but a chance.