I don't want to be a full-fullstack developer

companies and corporates have direct structural and economic incentives to commoditize work and development.

trying to find work that is intellectually stimulating, ethical, and not already a process flow or a prescribed solution is incredibly difficult, and even when you're notionally hired into such a position, you'll spend most of your life fighting against systems, incentives, training, culture and qualification institutions designed specifically to commoditized and throw up barriers to not thinking like 'pro in a box's. indeed, you might even say that the very notion of 'stack' of particular technologies is itself a materialisation of this concept. I'd love to say I've internalized the model of BA's, DB people, our other weird names for the job people do, but I can't. half of the time they aren't defined and the skills required to do them well are essentially the same. there, I've said it!

there's a real problem in that companies hire saying they want open minded and full stack, but all their behaviors are actually geared to want the opposite.

it's also why I try to do data science and not business or web development. I want open ended questions where things are genuinely not known, not IT specifications and requirements or building to spec. I would think the same drive infects a lot of people who choose the startup route (once you eliminate the tech fetishist fanboy circle-jerkers, if you'll pardon my French)...

H1B visa limit?

Once a company starts scaling up they’ll find that they need someone with a deep knowledge of one particular specialism, such as mobile development, or backend, or maybe infrastructure. They’ll pick someone like that up who likely ends up taking ownership of it.

Over time they’ll end up with specialists for everything, but that comes with its own set of problems. At this point probably everyone can do a really good job in isolation, but there’s someone needed to coordinate the work to make sure people aren’t being blocked. That’s when the first dedicated project managers start arriving and getting the team moving in one direction. Probably at this point you’ll also start seeing product managers, because there’s no one around with a unified high level view of what customers need anymore - everyone else is down in the weeds.

At least in my experience scaling a technical team is at least, if not more, complex than scaling the actual product that team is working on. It shouldn’t be underestimated, and you should aim to have someone around who’s done it before and understands when it’s time to stop saying “we should just hire people who can do everything”.

What about GPs?

Just like the medical field, software needs both specialists (to go really deep down the rabbit holes), and generalists (to tie everything together).

Personally I love being a generalist. Sounds like the OP just isn't in quite the role for them.

* From the early microcomputer era onwards, applications development focused on getting developers that knew the base platform or operating system(e.g. if you knew "Win32" dev, that was solid in the mid-90's) - and it was one platform per category of application, and for applications that integrated a database you also had platforms like Foxpro, Access, or Hypercard. Specialization beyond that was typically the domain of big-iron computing, which had an older market and talent pool that was used to a certain model and infrastructure of scaling to solve the data processing needs of the era.

* Increased usage of computer networking pushed all development towards a multi-tier setup(e.g. LAMP stack or the multifarious forms of Java and .Net), meaning that more applications needed "front-end" vs "back-end" division, regardless of their needs. We addressed the problem at a local level by gluing together big-iron concepts and microcomputer concepts to get an awkward-yet-servicable jumble of domain competence, with the Web as the dominant frontend. A very small number of Internet companies pushed the boundaries and set the standards on data processing and frontends, and the market followed in their footsteps and used their leftovers.

* Now that we have built out a lot of leverage towards all the possible speciality roles and computing is firmly in the hands of a few giants that can leverage all of that specialization, commoditization is creeping in and pushing smaller development teams back into more consolidated platforms. "The browser is the OS" is effectively true today, except that it's a terrible OS, scarred by numerous wars to control the platform and enable only specific categories of applications.

What developers are moving towards, but are having trouble reaching because of the sheer number of established layers and protocols and required features, is another Hypercard that consolidates concepts into a single consumable, more uniform package, without requiring you to know all the boundaries and sharp edges that exist when going between the JS type system, the SQL engine, the browser engine, serialization protocols, network conditions and hardware status, etc. This is not a project that can be accomplished by lightly papering over the existing systems with framework glue - it requires attention to detail to clean up and simplify each part of the whole. So it takes time.

But at the same time, I think we're also going to get where we want to go, faster than we think. The introduction of, and adoption of Web Assembly, is a major milestone because it raises the level of local processing and hence local platform consolidation, which in turn limits browser-specific APIs to importance in terms of their core I/O functionality, and not one-off standardized features. New platforms can carve out more and more space from that starting point, ultimately resulting in applications that have replaced the browser with a custom native runtime, but still ship WASM binaries.

Simultaneously, native code development is getting better. The bottom of the stack is getting attention after leaning heavily on the traditional C/Unix model for decades and accumulating features without major revision - Rust and systemd are two healthy(if polarizing) examples.

And at that point, the classical Open Web is dead, but it's due to be replaced in turn with a second coming of specialized, decentralized and federated protocols - new takes on Usenet, IRC, FTP, etc. The wheel will keep turning, though all the formats might churn.