How Cursor offloads the 20% to Unified, so the team can build the 80%

When we asked about his current Cursor workflow, he opened with a confession: he’s been using Mobbin less than he used to. This is not, traditionally, how a customer story begins. We liked it, because it turned out to be the more interesting one anyway.

“I haven’t been referencing Mobbin as much as in previous roles. Right now I’m working primarily on our redesigned desktop app. At Plaid, there was a lot of dashboard stuff — the entire team was always seeking data visualization inspiration. These days, a little less so. But I think in general, it speaks more to how design processes are changing, especially at AI-forward companies.”

It’s the kind of thing you hear from a designer who now ships his own code. “I used to joke about wanting to go my entire career without pushing a PR. That’s no longer possible.”

What’s changed isn’t whether he uses Mobbin, but what he uses it for.

Why there’s less to reference at Cursor

At Brex and Plaid, John was designing things other companies had already designed — dashboards, data visualizations, financial workflows. The point was pattern recognition: users had seen products like these before, and the job was to feel familiar, not foreign.

“Both Brex and Plaid are fintech. A lot of the work had to do with setting up a dashboard, a lot of data viz. That’s the type of work that benefits from referencing or auditing existing products. Not because the designer is looking for stuff to copy — more because we’re looking for patterns or trends our existing user base might already be familiar with.”

Cursor is different. It’s an AI-native code editor, and its core experience — agents writing code, the chat interface, the loading states, the multitasking flows — has no clean analogs. There’s no other product to study besides the direct competition. And the gap only widens as Cursor builds beyond code, toward features for designers, PMs, and other knowledge workers. The team is, quite literally, working without a map.

“The biggest difference in working at a team and a pace like this is that you are forced to ruthlessly prioritize.”

Mobbin for the 20%

John’s attention budget is explicit. 80% goes to the new features on the desktop app, the agentic core. The other 20% goes to the non-core but still necessary work: settings, billing, admin, enterprise plans. That 20% is where Mobbin earns its place.

“It’s a necessary thing to design for, but we want to spend 80% of our time on the new features. In those cases, we look for the most obvious solution. And occasionally, a clever solution.”

A recent example: enterprise groups and plans.

“It’s very important for the business. However, tried-and-true established patterns already exist. You don’t need something entirely novel. In fact, the more familiar patterns are more useful. I was using Mobbin to reference how other products document team setups — for the most part it’d be a table or a set of pages within a web admin dashboard.”

He’s clear about why:

“When most of your product surface is on desktop (and soon mobile), you’re not thinking as much about signup modals or web dashboards. It’s much easier to stick with what works and apply it to our users’ needs, get it designed, and move on to the bigger design challenges.”

That’s the role Mobbin plays here. Inventing the frontier is the team’s job, and the part worth their best hours. The settings page, the billing flow, the admin table: someone has already solved all of it. Mobbin is the reliable default for that work, so nobody burns an afternoon redesigning a settings page from scratch.

The competitor-watching trap

A related thread came up unprompted, about how Cursor handles looking at direct competitors.

“The Cursor team generally has a keen eye toward competition. Sometimes an engineer will say, hey, I saw something on [a competitor] that I really like, let’s incorporate it. To me, that can be a trap. It’s important to take away what and how we might incorporate a similar value add. But ‘they changed their buttons to be colorful’ is not necessarily useful or immediately relevant. It can result in a reactionary design culture, which I wouldn’t want to foster.”

His rule for the team:

“If we want to do something that feels like it’s an invitation, we have to strive to do it better — not just do table stakes.”

Mobbin is the opposite of that trap. It widens the lens. Watching one competitor tempts you to copy what you can see; Mobbin shows you how dozens of apps, most nowhere near developer tools, solved the same problem underneath. The aim is less about matching what a rival shipped, and more about understanding why it worked in the first place.

Discovery, not just auditing

One thing John flagged caught us off guard: his most-used Mobbin surface lately isn’t the library at all, it’s the weekly email.

“Previously, discovery of new apps and products was a little bit tricky for me to keep up with. Having apps added to Mobbin in the form of the email digest has been really useful. I get a glance of maybe a new app that went viral, or a new tool that is secretly very interesting that I wouldn’t have discovered on my own.”

He also pointed to a recent Mobbin YouTube teardown on onboarding flows that made the rounds inside his team while they were actively working on onboarding.

“My team was working on some onboarding flows for web, and it came up. People were having discussions about it in Slack. The data points and the framing — that multi-step onboarding flows can still have really good retention — that was top of mind.”

He summed it up:

“These days I’ve been getting a lot more value out of product discovery than just product auditing from Mobbin. I’m curious to see what you build next.”

Before Mobbin

We asked the question we ask everyone: what was the workflow before?

“It was a pain. Myself or a PM or anyone driving a project would do an actual audit, with documentation. At Plaid or Brex, we’d go through other financial products, make an account, sign up, screenshot a few things, drop it into a doc. That was a big workflow at Lyft as well — I’d screenshot things from Google Maps or Apple as UI reference points. It just made it very, very difficult.”

What if Mobbin went away tomorrow?

“I would imagine I’d go back to that workflow. Although — one thing you guys will have to deal with is that with the rapid rate of iteration these days, how do you keep your screenshots up to date? Things are changing every day. It does feel like the industry is getting faster and faster with iteration.”

He’s right, and we’re working on it. Flow versioning is coming, so teams reference fresh screens instead of stale ones.

“All my homies love Mobbin. I mean that. I finally deleted that folder of 1,866 unorganized screenshots and haven’t looked back since. Shoutout to Jiho and the team for doing God’s work.”