From Frontend to Full-Stack: My 11-Year Journey

I started writing JavaScript professionally in 2015. jQuery was everywhere. React had just hit 0.14. "Full-stack developer" meant a PHP guy who also wrote some CSS.

Eleven years later, I lead frontend teams at a digital agency, ship indie products in Swift and Electron, and argue with an AI assistant about whether my code is production-ready. The 2015 version of me would not believe a single sentence of that.

But this is not a highlight reel. The interesting parts are the years I got stuck, the bets I got wrong, and the stuff nobody tells you about career transitions.

2015: FTP and Pray

My first frontend job was in Brazil. I wrote jQuery plugins and spent entire afternoons making things work in Internet Explorer 8. The deployment process was FTP. Literally drag files into FileZilla and hope nothing breaks.

The stack: HTML, CSS, JavaScript — the ES5 kind, before arrow functions were legal. jQuery. Bootstrap. The occasional !important that I am still ashamed of.

Full-stack was a different species. Those were the PHP and .NET developers who sat on the other side of the office. We did not understand each other's problems. We barely shared a language.

2016-2017: The React Bet

React showed up and senior developers hated it. "It's just JavaScript in HTML." "What about separation of concerns?" "This will never catch on."

I remember being in a meeting where the tech lead said React was a fad. He was a smart guy. He was wrong about this.

I bet on React anyway. Spent nights learning while delivering jQuery during the day. Started sneaking React into projects — "progressive enhancement," I called it, which was technically true and politically useful.

By 2017 it was obvious. The component model, the virtual DOM, the idea that UI could be declared instead of imperiled — it was not a new library. It was a different way of thinking.

The seniors who resisted eventually came around, but they lost two years. That taught me something: when a technology feels fundamentally different — not just different syntax for the same thing — pay attention. The skeptics are usually right about the rough edges and wrong about the trajectory.

2018-2019: Hitting the Wall

Two years of React made me fast at building UIs. It also made me dependent on other people for everything else.

I would finish a frontend in three days and then wait two weeks for the backend team to build the API. I needed an endpoint changed — ticket filed, sprint planned, merged next month. I wanted to add a feature — "talk to the backend team."

The frustration was not about ego. It was about being unable to finish what I started. The dependency was suffocating.

So I started learning Node.js. Not because I wanted to be "full-stack." Because I wanted to stop waiting.

// My first Express API, circa 2018.
// The code quality was genuinely bad.
app.get('/api/users', function(req, res) {
  db.query('SELECT * FROM users', function(err, results) {
    res.json(results);
  });
});

No TypeScript. Callbacks everywhere. SQL injection vulnerabilities I did not even know existed. But I could ship end-to-end. That single capability changed everything that came after.

2020-2021: Geography Stops Mattering

COVID made everyone remote. For a developer in Brazil, this was seismic.

Before 2020, my options were local companies or the rare remote-first startup that recruited internationally. Suddenly, US and European companies were hiring globally and paying globally. The Brazil-to-US-East-Coast time zone overlap is 1-4 hours depending on daylight saving — close enough to attend standups, far enough to get deep work done in the morning before Slack explodes.

I went from competing with developers in my city to competing with developers everywhere. That sounds scary. In practice, it meant access to companies that would never have found me, paying rates that did not exist in the local market.

The LATAM time zone advantage for US clients is real and underappreciated. We are not cheap labor. We are same-day-turnaround labor in a convenient time zone.

2022-2024: The Systems Thinking Shift

At Planetary, I moved into technical leadership. The role demanded understanding the full picture — frontend architecture, API design, database modeling, deployment pipelines, client communication.

I was not the best at any single piece. The backend specialists knew more about database optimization. The DevOps engineers understood infrastructure better. But I could see how the pieces connected. I could explain to a client why their "simple feature request" required a database migration that would affect three microservices. I could tell a designer that their carousel idea would double the page weight and suggest an alternative.

That systems thinking — understanding how a frontend decision ripples through to the backend, how a database schema constrains what the UI can do — became more valuable than any framework expertise.

Full-stack does not mean expert at everything. It means fluent enough in each layer to make decisions that do not come back to bite you.

2025-2026: The AI Acceleration

Then AI coding tools arrived. Not the hype cycle — the actual, daily-use tools.

I use Claude Code for 70% of my coding time now. Not because it writes my apps. Because it handles the parts that used to eat my evenings — boilerplate, repetitive transformations, build validation, the boring-but-necessary work that separates "I have an idea" from "I have a working commit."

Here is what surprised me: eleven years of experience became more valuable, not less. When Claude suggests an implementation, I can evaluate it. I know the edge cases. I understand why certain patterns exist. I catch the subtle bugs that look correct to someone who has not been burned by them before.

Junior developers using AI tools code faster. They do not necessarily make better decisions. The AI is only as good as the human steering it. Experience is not about knowing the syntax — it is about knowing what questions to ask.

What Still Matters After Eleven Years

Problem decomposition. Taking a vague requirement like "add user authentication" and breaking it into concrete decisions — session vs. JWT, where to store tokens, middleware structure, error handling. AI can implement any of those. Someone still has to decide which ones to implement.

Reading code. I spend more time reading than writing. Understanding existing codebases, reviewing PRs, debugging production issues. This was unglamorous in 2015 and unglamorous in 2026. It was valuable in 2015 and more valuable in 2026.

Communication. Explaining technical tradeoffs to non-technical stakeholders. Writing documentation that someone other than you can understand. Articulating why "just add a button" is actually three sprints of work. This transfers across every technology shift because the technology is never the hard part. People are the hard part.

Learning how to learn. I have picked up jQuery, Angular 1, React, Vue, Node.js, Next.js, Swift, Electron, and a dozen other tools. The specific knowledge becomes outdated. The ability to get productive in something new within a week does not.

What Stopped Mattering

jQuery mastery. I was genuinely good at jQuery. Complex animations, plugin development, cross-browser hacks. Completely irrelevant. Years of expertise, useful for exactly zero of my current work.

Webpack configuration. I used to spend days optimizing Webpack configs. Now frameworks abstract this away and I am grateful. Nobody should have to understand Webpack in 2026.

Manual browser compatibility. We used to test in IE8. We wrote vendor prefixes by hand. We cared about which CSS properties worked where. Modern tooling handles this. The suffering was real but the knowledge is worthless.

CSS architecture. SMACSS, BEM, OOCSS — I had elaborate opinions about CSS methodology. Tailwind made most of it unnecessary. The old arguments feel quaint now, like debating the best way to sharpen a stone tool.

What I Would Tell 2015-Me

Learn TypeScript now. I resisted for too long. TypeScript is not optional anymore — it is the baseline. Every year you wait is a year of bugs you could have caught at compile time.

Stop identifying as a React developer. React is a tool. Being good at it is useful. Being unable to work without it is a trap. The developers who thrive across eleven years are the ones who hold their tools loosely.

Build something that is yours. Not for the portfolio. For the learning. Side projects force you to make every decision — database, auth, deployment, pricing, marketing. There is no substitute for the complete picture, and you will not get it at a company where someone else handles the backend.

The backend compounds. Every hour spent understanding databases, APIs, and infrastructure pays dividends for years. Frontend-only developers hit a ceiling faster than they expect. The ceiling is not technical. It is influence — you cannot lead architecture decisions when you only understand one layer.

For Developers Starting Today

The entry path is harder now. The "just learn to code" advice from 2015 needs a serious asterisk. AI tools mean the bar for what an entry-level developer produces has risen, while the demand for entry-level engineers has fallen.

What I would prioritize: fundamentals first (how browsers work, how HTTP works, how databases work), one framework learned deeply instead of three learned superficially, and the ability to ship end-to-end. A junior developer who can take a feature from database schema to deployed UI is more valuable than one who can build beautiful components that need someone else to wire up.

And learn to read code. Contribute to open source. Read framework source code. Most developers cannot read code they did not write. This is a superpower that takes years to develop. Start now.

The Longer View

Looking back at eleven years, the specific technologies were the least interesting part. jQuery, React, Node, Next, Swift — tools I picked up and will eventually set down when something better arrives.

What mattered was the ability to learn fast, ship consistently, and not attach my identity to any single tool. The developers who struggle through technology shifts are the ones who made a framework their personality. The ones who thrive are the ones who stayed curious and stayed uncomfortable.

I do not know what the next eleven years look like. AI might change everything. Or it might become a normal tool, like the IDE before it. Either way, the ability to decompose problems, communicate decisions, and ship working software will still matter.

Everything else is implementation detail.