The fullstack developer role has a scope creep problem nobody talks about honestly.
You were hired to build features. Frontend, backend, maybe some database work. Ship product. That is the job.
But at some point the CI pipeline broke and you were the one who fixed it. Then the staging environment was misconfigured and you sorted it out. Then a service stopped talking to another service in production and you spent three hours figuring out it was a network policy. Then you wrote the Kubernetes manifests because nobody else was going to.
None of that was in the job description. But here you are.
Why this keeps happening
The gap between writing code and running code has never fully closed. Fullstack developers sit right at that boundary and end up absorbing work from both sides. The infrastructure is too complex to be invisible but not complex enough to justify a dedicated platform team at most companies.
The result is a developer who is half building product and half managing infrastructure, context switching constantly between the two, and doing neither as well as they could.
What actually helps
The abstraction layer needs to sit in the right place. Instead of a fullstack developer caring about Deployments, Services, Ingress rules, and NetworkPolicies, the platform should let them express what they need in terms that make sense for their work.
I want to deploy this API. I want it reachable from this frontend. I want it exposed on this path. I want separate instances for dev and prod with different environment variables.
That intent gets compiled into the necessary Kubernetes resources, network policies, gateways, and observability hooks without the developer ever touching the underlying primitives.
The developer stays in product mode. The platform handles the infrastructure translation.
APIs are exposed through gateways with built-in support for routing, rate limiting, authentication, and traffic policies without requiring manual configuration. Things that would otherwise take a fullstack developer a day to wire up correctly become a declaration.
Where I saw this in practice
I contribute to OpenChoreo, an open source CNCF project built around this idea. The whole abstraction model is designed so that developers can ship services without needing to understand the full surface area of Kubernetes. Working on it gave me a much clearer picture of where the abstraction boundary should sit.
The goal is not to hide infrastructure. It is to make it someone else’s problem by design.
Has infrastructure creep eaten into your product development time? Curious how fullstack teams are handling this at different company sizes.
_If you want to see what the developer experience looks like: _<a href="https://openchoreo.dev/" target="_blank" rel="noopener nofollow">https://openchoreo.dev/</a>

This squad was created to support resource sharing within the Fullstack Developer community. Developers can post anything related to software development.

Fullstack Developer

Fullstack developers are increasingly absorbing DevOps responsibilities they never signed up for — fixing CI pipelines, managing Kubernetes manifests, debugging network policies — due to the gap between writing and running code. At most companies, infrastructure is too complex to be invisible but not complex enough to justify a dedicated platform team. The proposed solution is better abstraction layers that let developers express intent (deploy this API, expose it on this path) while the platform compiles that into the necessary Kubernetes resources, network policies, and observability hooks. The author draws on experience contributing to OpenChoreo, an open source CNCF project designed around this developer-first abstraction model.

Fullstack developers are quietly becoming accidental DevOps engineers. Nobody signed up for this.