Why not to be a frontend or backend engineer
Specialisation feels safe. It’s also a cage. Here’s why I went full-stack — and what it actually unlocked.
The T-shape argument is incomplete
You’ve heard the T-shape: deep in one area, broad across others. It’s reasonable advice for large companies.
But here’s what nobody says: the T assumes you’re always on a team where your depth gets leveraged. At a big company, your frontend skills are complemented by a backend team, a DevOps team, a QA team.
When you’re building something solo, or early at a startup, that team doesn’t exist. You are the team. If you can only do one layer, you’re constantly blocked or dependent on someone else.
What full-stack actually unlocks
Speed. Ownership. Startup ability.
When I was purely frontend at my early jobs, I’d hit a wall every time I needed a new API endpoint. Either I’d wait for backend to build it, or I’d write a hacky workaround in the frontend. Neither was good.
When I went full-stack, I shipped end-to-end features alone. I understood the system from database to UI. I could debug anything. I could own a product.
That ownership is what let me build MagicSell solo. Not “I can do both frontend and backend” — but “I can build and ship an entire product by myself.”
How I’ve used it across companies
At Razorpay — backend in Go, payment flows, reliability work. Also jumped into React dashboards when needed.
At JioHotstar — SEO infrastructure, Node.js, React. Worked across the stack on the same project.
At Deel — backend systems, but understanding the full system means I can diagnose issues faster and contribute to decisions that span layers.
At MagicSell — everything. Product, UI, backend, infrastructure, billing, auth. No handoffs. Just ship.
Each of these required being comfortable across the stack. Specialisation would have been a constraint, not a strength.
When specialisation makes sense
At a company with 200+ engineers, there’s value in going deep. Infrastructure specialists, security engineers, database experts — these roles exist because the problems are genuinely hard and narrow.
But early in your career or if you want to build a product, staying in one lane will slow you down.
How to go full-stack without starting over
Pick your weakest layer and get comfortable with it, not expert in it.
If you’re a frontend engineer: build a simple REST API with Node or Go. Connect it to your existing frontend. Ship it to a real server. You’ll learn 80% of what matters in a few weeks.
If you’re a backend engineer: build a small UI with React. Don’t try to master CSS — learn enough to ship something. The goal is fluency, not mastery.
The takeaway
Being full-stack is a superpower when you want to build a product, join an early startup, or move faster. Specialisation has value at scale. But most engineers hit their ceiling because they can’t own a full problem end to end.
Building something? Follow me on Instagram and Twitter — I document everything.