Frontend Developers: the Newest New Kingmakers with Kate Holterhoff from RedMonk
Kate Holterhoff noticed Supabase — a database company — was explicitly targeting the frontend developer as its buyer. Around the same time Vercel rebranded as "the frontend cloud." She thinks that's not a coincidence — it's a kingmaker shift back to the client side.
Kate Holterhoff is a senior analyst at RedMonk, the developer-focused analyst firm, and a former frontend engineer with an unusual path into tech — a decade as an academic studying 19th-century literature before moving into industry. She's the author of a three-part RedMonk series on the resurgence of the frontend developer as a purchasing-power kingmaker.
We get into why she thinks the term 'full stack developer' has quietly become a disservice to how good frontend work actually is, which companies are already building for a frontend buyer instead of a backend one, and her genuinely striking prediction about where AI-driven abstraction leaves the very idea of a 'developer' job title within a decade.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What made you want to write about frontend developers regaining influence?
Having been a frontend engineer myself, I had a vested interest in reclaiming the title, honestly — I'd get to a Christmas party, say I was a frontend developer, and people would treat it as less serious, like 'we don't have frontend developers on our team, only full-stack developers.' That frustrated me, because the frontend engineers I worked with were extremely sharp, and a lot of the most interesting innovation I was seeing as an analyst was happening client-side. What actually pushed me to write it was hearing Paul Copplestone, CEO of Supabase — a database company — say on a podcast that they were explicitly targeting the JAMstack. That seemed remarkable: why would a database company care about validating the frontend? Around the same time, Vercel rebranded as 'the frontend cloud,' and I thought, something is happening here.
Why do you think the term 'full stack developer' has actually been a disservice to frontend engineers?
Nobody actually wants to manage an entire stack — it's too much for one person. I dug into the history of the full-stack developer term and talked to people in the industry about what it's really asking of people, and it does a disservice to developers by treating the frontend as something incidental to a bigger job, rather than recognizing that meaningful, specialized work — design sensibility, accessibility, UX — happens specifically on the client side. Chris Coyier's 2019 piece 'The Great Divide' captures this transition well: frontend developers aren't just people who can't yet manage backend infrastructure, they're often drawn deliberately to the parts of the job that live in the browser.
Where does WebAssembly fit into this shift?
At KubeCon, all the discussion I heard was about WebAssembly — and if the compute that used to require backend infrastructure is moving onto the devices themselves, into the frontend, that's a genuinely big shift. It reinforces the same point: the innovation and excitement happening on the frontend can't be dismissed as secondary to 'real' backend engineering anymore.
You've made a striking claim that we might not recognize what developers do in ten years. What's driving that?
A lot of what frontend engineers do today is stitch together third-party services — using something like Supabase for auth because it's bundled in, which takes away the fiddly parts of backend engineering so they can focus on work they actually enjoy. I talked to engineers who ended up stuck maintaining YAML files despite that being nowhere near what drew them to the job. The direction of travel is toward more managed services, more serverless, less of that fiddly ops-adjacent work, and more time on the parts people actually find engaging — I could lose hours happily building out a web page as a frontend engineer in a way I never could with other tasks. On top of that, AI code assistants have gone from novelty to invisible infrastructure extremely fast — at DevNexus recently, every single demo I attended had some AI code assistant baked into the workflow, and nobody even called it out as notable anymore.
How does this connect to RedMonk's original 'kingmaker' idea?
My colleague and RedMonk co-founder Steve O'Grady coined 'kingmaker' about a decade ago, mostly thinking about backend developers — his go-to example is Slack getting adopted bottom-up at IBM: developers just started using it for internal communication, and leadership eventually had to invest in it because it was already how the org actually worked, not because it was handed down from the top. I think we're going to see more of exactly that dynamic among frontend engineers specifically, as they push back against being treated as an undifferentiated 'full stack' resource and focus on what they're actually interested in.
Is the line between designer and frontend engineer actually dissolving, not just shifting?
I think we're going to see real muddying between what designers and frontend engineers do. When I was a frontend engineer, there was an elaborate handoff: UX designers made wireframes, handed them to a design team who turned them into a PNG with colors and image choices mapped out, who handed that to frontend engineers to actually code — three separate teams. Tools like Vercel's v0, where you describe in natural language what you want — 'a card like a Twitter card, with these sections, centered text' — and get working output, mean a UX designer, a visual designer, a frontend engineer, or frankly a project manager could all now produce that first pass themselves. The capability gap between people who can code and people who can't is genuinely narrowing.
What should a devtools company actually do differently if it wants to win over frontend developers specifically?
Get the time to 'hello world' as short as possible, and offer a real tinkering tier — a free tier that's rate-limited rather than time-limited, because nobody wants to invest effort building something like a small permanent site for their own wedding if it's going to disappear after a trial period ends. Speak to frontend developers directly rather than folding them into 'full stack' messaging they don't feel addressed by, and make sure you have real integrations into the JavaScript ecosystem even if your core product is built in something like Rust — SDKs for the frameworks they're already using give them an actual on-ramp. There's also something less tangible: frontend engineers are drawn to design as a discipline, so a landing page that looks like it hasn't been touched in ten years signals you're probably not maintaining the actual product either. Vercel's whole aesthetic — even down to the black t-shirts — is not incidental to why frontend developers gravitate toward it.
Is it too early for tools to target the layer above developers entirely — product managers using something like v0 directly?
I'd say the closest thing we have today is low-code/no-code, and developers broadly are more antagonized by that than frontend developers specifically are — I'm personally more comfortable with no-code and low-code than most of my RedMonk colleagues. There's a real morale cost to the alternative: I've talked to engineers, more often on the ops or backend side, who spent six months on an internal project only to have it thrown away when the product manager changed and it never shipped. If AI and automation make prototypes cheap and ephemeral, a product manager can build and test their own idea without spending anyone else's time on a prototype that might get discarded anyway. If you're marketing a low-code or no-code tool today, the product and design team is probably a more receptive audience than developers themselves, though it really depends on the use case.
What's your one piece of advice for devtools founders thinking about where this is all heading?
Don't discount frontend engineers. They're smart, they have more purchasing power than they're usually given credit for, they're actually making a lot of these adoption decisions, and I think they're at the leading edge of some of the most innovative things happening in web apps right now.