Ultimately, the most important thing to keep in mind is that your “stack” shouldn’t define you.
While I agree with this advice in general, there are cases in which it is advantageous to allow your stack to define you. For example, Jane Street Capital appears to have established themselves as the place to work if you are interested in both functional programming and finance, greatly aiding their recruiting efforts.
Granted, they didn't start out using OCaml; their founders made a switch after the firm had already established itself. However, I wouldn't be surprised if a startup (where the founders have a specific skillset/background) could exploit a similar first-mover advantage.
Not to mention that without a lot of ACTIVE effort to make the stack NOT define you it will. The stack will strongly influence who you hire and who you hire will easily come to define you. A bunch of C/C++/Java/Rust/Go folks are going to have a different value set than a bunch of PHP/Ruby/Perl guys. Not to say their isn't overlap in people or ideas, but people who are attracted to similar technologies are often more self-similar compared to people attracted to other technologies. Depending on the problem space a given technology and the mind-sets that come with it by default may be or less helpful.
That may be more of a case of the stack reflecting you than defining you. The distinction I'm drawing is whether you allow external perceptions to influence your decision.
To try to be more clear, I'll make up an example. Say you as a founder are a Ruby guy, perhaps you value being able to rapid prototype, throw away code, iterate quickly.
Maybe your product needs to be very high performance so you hire a team of C programmers. What you might find is that their idea of iterating quickly is on a different timescale than yours, due to the low-level and unforgiving nature of C perhaps your team tends to be pedantic (by your standards) or correctness/detail oriented (by theirs).
In this situation your team, influenced by your technology choice, is bringing a different value set than your own to the table. BUT this is not (necessarily) a bad thing, if C really is be best tech for your product your team can strive merge both your and their values; however, my point is without you actively trying to do that, your tech just defined the value set, not you. (In this case it also possible that maybe Rust or Go would have been better tech, but that is a different conversation)
Agree. I wouldn't treat it as a rule. Normally it's the right thing to start with solving user problem, but I see many successful businesses built on trying to find application to the "new cool stuff". Github is one more example of the company driven by technology choice first.
While I agree with this advice in general, there are cases in which it is advantageous to allow your stack to define you. For example, Jane Street Capital appears to have established themselves as the place to work if you are interested in both functional programming and finance, greatly aiding their recruiting efforts.
Granted, they didn't start out using OCaml; their founders made a switch after the firm had already established itself. However, I wouldn't be surprised if a startup (where the founders have a specific skillset/background) could exploit a similar first-mover advantage.