The Rise of App Bros and the Fall of Thoughtful Product Design

App Bros

Every other post on Threads now is someone launching their own task tracker, budgeting app, or AI-powered journal. App Bros are on the verge of replacing Podcast Bros at the top of the slop-generation hierarchy. This is what happens when the entry barriers drop, so anyone can confidently produce something in a field where they have zero expertise, with full conviction that the world has been waiting for their contribution. This is what usually gets called “democratizing [insert industry here]” in pitch decks.

“Launching a startup” now takes a few weekends in Claude Code, a Twitter thread about shipping an app in forty-eight hours, a Product Hunt launch, a three-tier SaaS pricing table, and fifty users, most of whom are other App Bros on the free tier.

Building used to be slow, expensive, and hard. You couldn’t afford to build the wrong thing, so you argued about what to build for months before you started. There was real thinking behind every decision. That was design work, even when nobody called it that. Now the slowness is gone, and the building has become essentially disposable. The whole thinking behind thousands of lines of code can now be “build me a CRM, don’t make mistakes.”

The problem with “prototype in code, polish in Figma”

A common claim I hear lately from designers is that their process has changed. They prototype in code first with v0, Lovable, or Cursor, get a working interface in minutes, and then pull it back into Figma to “refine” it. The framing is that this is more real, closer to shipping, because you’re working with actual components and actual interactions instead of “pushing rectangles” around on a canvas.

There are two problems with this. The first is anchoring. A generator produces the average of its training data, which in SaaS means ShadCN-ish dashboards, tried-and-tired navigation patterns, and the purple-gradient-with-a-sidebar aesthetic from Dribbble. “Refining” that output is not designing from first principles. It’s decorating a template that you did not even choose, because the model chose it for you. And because the first draft usually looks plausible and real, you never go back to ask what this product could have looked like if you had started from the problem instead of the template.

The second problem is worse. Refinement presumes you understand the decisions you’re refining. In traditional design those decisions were yours. You put the search bar where it was because you thought about where the user’s attention landed first, what they were likely to do in that moment, and how many other elements should compete for their focus. Everything had a reason, and even when the reason was wrong, you could test it and come back with either a result or a learning. Surprisingly, the learnings were often the most valuable part, because they helped you formulate better hypotheses and understand your audience.

Now, when the generator hands you an interface, there are no hypotheses to test. The search bar sits where it does because similar interfaces in the training data tended to have one there, not because anyone seriously weighed the alternatives and decided on this one. Most AI designs look like most other AI designs, so the thing probably works somehow, but it likely won’t be a hit. And then it’s very hard to iterate on, because you don’t know why it works or doesn’t, because you never made any decisions about it and have no alternatives or reasoning to compare against.

And if your plan is to iterate your way to success because building is cheap, what is your value as a designer? After stakeholders hear your reasoning for a few UI tests and it keeps coming down to “AI produced it, it’s easy to build, let’s just test it,” they will do a simple calculation on the ROI of your involvement, and… let’s just say you won’t like the results.

The work upstream

The designers still worth keeping in the room are the ones who already know what they want before they open Cursor, Claude Code, Stitch, or Variant. Not in the sense of having the exact wireframes in their head, but in the sense of having done the unglamorous work of talking to actual users, mapping key pain points, flows, and steps on the path to value. They already know which problems are worth solving and which ones only look like problems, what the product is and, most importantly, what it is not.

If you skip those steps and let the model start for you, you are not designing. You are just curating. Curation is a fine skill, but it is not a scarce one, and it rarely pays well. Otherwise all the Pinterest users would have monetized it already.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.