August 13, 2026
Functionality in a Vacuum Nobody Needs
I look at yet another product built by a team of strong engineers — and it’s the same picture I’ve seen dozens of times.
By Angelina Chuprina
1 min read
Fast. Nothing lags. The code, from what I can tell, is clean. And it's impossible to actually use.
Because when a product is built by developers alone, you usually end up with functionality in a vacuum. They solve the engineering problem — and solve it well. But they almost never stop to ask who's actually going to use this. What state that person is in when they open the app. What pain brought them here, and what needs to happen in the first 10 seconds so they don't just close the tab.
This isn't a question of skill. It's a different job entirely. A developer thinks in terms of "how do we build this," not "why does a human need this, and at what moment in their life."
So on any team, there needs to be someone who holds the audience and the bigger picture in their head. Doesn't have to carry the title "product manager" or "designer." Just someone who asks "who actually needs this, and why" before anyone asks "how do we code it."
And here's what's especially interesting to watch right now: without that person on the team, a technically flawless product gets quietly outpaced by services thrown together by people who'd never written a line of code before. Vibe-coded, held together with AI tools and good faith, rough around the edges. But built by people who understand their audience in their gut — because they are the audience.
And honestly, that's fair for the market. Users don't care what stack a product runs on or how elegant the architecture is. They need a solution to a specific problem, right now. If it closes their pain point, they'll forgive the rough edges. If it doesn't, no amount of clean code will save it.
As a designer, this isn't a moment for me to gloat over developers — the reverse happens just as often: a product dreamed up by someone with a great sense of their audience but zero engineers on the team, which collapses under the first real load or never makes it past a prototype.
The conclusion is boring, but no less true for it: strong products happen at the intersection. The person who knows how to build, and the person who knows who it's for and why — they need to be at the same table from day one, not meet up at the "okay, we're done, now let's polish the UX" stage.
**So — on your last project, who was the first to ask **"does anyone actually need this?"