When Your Users Rebuild Your Product

User modifications are the best product research you'll never commission.

---

In March 2026, a designer named Max Drake used Claude Code¹ to modify her own Spotify desktop app.[electron] She added a BPM graph visualization at the top of her playlist view and a BPM column in the track listing. Her post afterward read: "update: this worked????"

She hadn't filed a support ticket. She hadn't posted a feature request or upvoted a community thread. She described what she wanted to a coding agent and thirty minutes later she had it.

Her surprise was the tell. She expected friction and found none. That's the moment product teams need to pay attention to. The lesson is in what the modification means for the roadmap.

Why the skill floor matters

Power users have always modified software. Ad blockers were an early mass-market form — millions of people deciding, without asking permission, that the designed experience should look different. Greasemonkey scripts, browser extensions, custom CSS injections[greasemonkey] pushed further but required enough technical knowledge to stay niche. This pattern goes back decades. The change is who can participate now, and how far they can go.

For a long time, user creativity inside platforms took one form. Reviews, photos, and videos were created within a product's constraints, on the platform's terms. That's user generated content. What's emerging is a layer deeper — user generated experience. The modification target is the product experience itself, shaped to fit a specific user's actual workflow.

Ryo Lu, head of design at the AI coding tool Cursor, built a personal operating system in afternoons of what the community calls vibe coding (a time-traveling browser, an iPod music player, a Mario game). He built a working prototype of Cursor inside Cursor to test its own features, because prototyping in Figma stopped feeling real enough. He said afterward: "the easier route right now is actually to just code."

The same leverage is available to your users. If a designer can prototype a working operating system in a few hours, a user can modify your settings page in a few minutes. The bar moved from "can you program" to "can you describe what you want."

Max Drake's Spotify modification worked because Spotify's desktop app is built on Electron, a framework that packages web apps inside a browser shell. A coding agent with the right tools can read and rewrite the JavaScript running any Electron app. Electron is an illustration, not a special case. Browser automation, accessibility APIs, OS-level scripting. Every surface a coding agent can reach is one your users can modify without asking permission.

The practical question for product teams is what their users would change if they could change anything.

Some of them are already answering it.

Signal, not threat

When evidence of user modification surfaces, the instinct is often defensive. Lock it down, enforce the terms of service, patch the exploit.

That instinct misses what the modification is telling you.

Max Drake needed BPM data visible while browsing her playlist. Spotify had the data, since it powers its own recommendations. She built the interface Spotify hadn't shipped. That's a feature request that arrived with a working prototype attached. The researchers who commission surveys and run focus groups to understand what users want are chasing the same thing she handed Spotify for free: a specific, concrete need, a demonstration that it was technically feasible, and a clear picture of what the implementation could look like.

Zach Lloyd, founder of the developer terminal Warp, published a thread in March 2026 detailing how his company had stopped buying SaaS. His team replaced a hosted documentation platform by migrating all 266 pages to Markdown and a static site generator, moved from paid community monitoring subscriptions to an agent that watches social mentions, replaced Greenhouse UI workflows with agent-driven automation. In each case, the replaced product's value was primarily in the interface layer, sitting on top of functionality and data that an agent could access another way.

Those companies never saw it coming. Lloyd's team didn't file feature requests or submit feedback. They stopped paying and built replacements.

The speed of rebuilding is its own signal. When Granola, an AI meeting notes app, restricted access on its free tier, users who had built workflows around it started building alternatives. Working replacements appeared within hours. No product team can respond to a product gap that fast, but a team already tracking modification signals can see the pressure building before the replacements go public.

When users modify your product rather than abandon it, you're getting feedback that most churned users never provide. The modification is the signal. The question is whether you're set up to receive it.

The timing also matters. Companies rebuilding their workflows with agents don't announce it in advance. They cancel subscriptions after the replacement is already running. Modification signals, by contrast, surface while the user is still engaged. You have a window to respond that you don't have with churned users.

Playbook: Observe, Enable, Integrate, Monetize

There's no single right response to user modification. But the companies that treat it as a feature pipeline rather than a threat move through a recognizable sequence.

Observe

Modification signals arrive before you think to look for them. Search social media for your product's name alongside "Claude Code" or "Cursor" or "vibe coding." Check your API logs for unusual access patterns that don't match normal user sessions. Look at support tickets for screenshots showing modified interfaces. Users sometimes describe what they built alongside what broke.

GitHub is worth monitoring here too. If you publish an API, search for repositories that build on top of it. What integrations are people building that you haven't shipped? What data are they pulling that suggests a feature gap?

Warp's customers didn't broadcast their replacements. Spotify didn't know Max Drake modified their app until she posted about it. The companies in the best position are the ones who've built watches before the first modification surfaces publicly, so the signal lands in their backlog rather than surfacing in a Twitter thread.

Set up the watches first. What you find will tell you more about your product's gaps than any NPS survey.

Enable

Once you know modification is happening, the question shifts to quality. A user who modifies your product against the grain, working around your component structure and scraping data from inconsistent endpoints, creates something fragile. It breaks on updates. It's harder to learn from.

Designed extensibility produces better signals. Clean API design, semantic component naming, well-documented data schemas. These don't just make modification possible. They make modifications that are legible, stable, and informative about what users need.

MCP servers[mcp] are the most direct version of this in 2026. Figma's MCP server lets agents read and write to the design canvas directly. GitHub's CLI handles complete repository management without requiring a browser. Products that publish clean connection layers make agent-mediated modification more reliable, which means more users can do it and what they build is more representative of what the product could become.

The contrast is instructive. Datadog, a monitoring and analytics platform, is powerful and complex. Rather than learn its interface, you can have Claude Code pull raw data from Datadog's API and build a custom dashboard from scratch, tuned to whatever metrics you care about. The user never sees Datadog's designed interface. Datadog still captures the data and provides the API, but the product experience its team refined over years is bypassed entirely. Intentional extensibility would have let Datadog own more of that experience rather than having it routed around.

This also means product quality decisions have a second audience you haven't been designing for. When an agent is the user, it doesn't benefit from progressive disclosure, onboarding flows, or trust-building copy. It needs endpoints, documentation, and predictable behavior. A PM reviewing API design should ask not just how a human navigates it, but whether an agent can use it reliably with no guidance beyond the documentation.

If modification is going to happen regardless, you want it happening through surfaces you designed rather than surfaces you left exposed by accident.

Integrate

Gaming understood this before software did.² Counter-Strike started as a Half-Life mod built by a player who wanted something the original game didn't provide. DayZ began as an Arma 2 modification. Team Fortress was a Quake mod before Valve acquired the team. The studios that built lasting ecosystems figured out how to route player-built additions back into the main product.

Product teams have the same option. When multiple users build the same modification, that's a roadmap item with demonstrated demand. No survey required. The demand is in the builds.

The modification also tells you something a feature request doesn't tell you. It shows what the user was willing to do to get it. Max Drake didn't casually suggest that Spotify should show BPM data in playlists. She modified a running application to make it visible. That level of signal is different from a thumbs-up on a community feedback board, and it warrants a different level of response.

The integration question is straightforward once you've seen several modifications. What were enough users trying to build that it belongs in the core product?

Monetize

Plugin markets are the mature form. VSCode's extension marketplace, Figma's plugin ecosystem, Shopify's app store. Each one turned user modification from something that happened in spite of the product into something that strengthened it. Users who build modifications become invested contributors. The ecosystem adds surface area the core team couldn't staff.

Lighter versions are emerging. When users can share modifications with each other, quality filtering surfaces the best ones without requiring the company to manage curation. Users who've modified the product to fit their specific workflow have higher switching costs than users on the default experience. A user who customized their interface around a workflow need has a reason to stay that most users don't.

The economics are worth sitting with. A user who found your product worth modifying is more engaged than a user who accepted your defaults. That engagement is a retention lever, but only if the product enables and acknowledges the modification rather than patching it.

Data as the real moat

If users can rebuild your interface, your moat can't live in the interface.

Lloyd's Warp thread named what's being replaced. The products going first are the ones whose primary value was the interface, sitting on top of functionality and data that could be accessed another way. When coding agents can build a better-fitting interface from the same underlying material, the designed interface stops differentiating.

The moat lives in data you capture that agents can't derive independently, in network effects that compound with usage, in integrations that create switching costs, and in institutional trust built over time. Products built on these don't get replaced when users gain the ability to modify interfaces. They get extended.

Readwise, a reading app that captures highlights, notes, and clippings from books and articles, made a deliberate move in this direction. Recently it shipped a CLI and an MCP server, making its accumulated reading context directly available to agent setups. The choice signals where the product team sees the value. What compounds is the accumulated context, years of reading history that only Readwise holds. The interface is one of the ways to reach it.

I've been building something in the same space, and the same logic applies. A reading tool whose value is in the interface is replaceable. A reading tool whose value is in years of annotated reading history is not.

Products that think about their agent-facing layer alongside their human-facing layer retain value in both. Products that design only for human navigation find agents routing around them toward the data they need.

When scoping a new feature, ask whether its value is primarily in the interface or in the data and network behavior underneath. A well-designed UI for setting preferences is replaceable. Years of preference data that informs personalization is not. The features worth the most investment are the ones that deepen the data layer.

What this tells you about your roadmap

The companies that treat user modification as a feature request pipeline will ship faster than the ones fighting it. Their advantage is signal quality. A modification that arrived with a working prototype is worth more than ten survey responses, because someone wanted it badly enough to build it.

Start by setting up the watches. GitHub search, social search, API log patterns. Look for evidence of modification before it announces itself publicly. When you find it, look at what was built before you reach for a patch.

The modification is asking something. Most companies are too busy locking the door to hear the question.

Footnotes

1. Claude Code is Anthropic's coding agent, available as a CLI tool. It can write, run, and iterate on code autonomously given a task description, bridging the gap between "I want this feature" and "this feature exists in my running application." ↩

2. The game modding ecosystem has a long track record of user modifications becoming canonical features. Counter-Strike originated as a Half-Life mod in 1999. DayZ started as an Arma 2 mod in 2012. Team Fortress began as a Quake mod before Valve acquired the team and shipped it as a standalone game. The pattern of companies integrating the best user modifications has a thirty-year precedent in gaming. ↩