Familiar interface: Onboarding you don’t have to build

Cursor, the AI code editor, is a fork of Visual Studio Code. Calling that a shortcut around designing an editor undersells it considerably.

What a fork actually inherits is three things at once: users who already know every keyboard shortcut, an extension ecosystem someone else spent a decade growing, and a settings file that can be imported so the new tool arrives already configured the way its user likes. The onboarding is not short. There essentially is not one.

Forking is the strongest version of this pattern, and it comes with a bill attached that arrives later.

What you are actually borrowing, and what it costs

A familiar interface deliberately adopts the layout, interaction model and vocabulary of a tool your users already use, so that competence transfers on arrival instead of being taught.

It is not a visual resemblance. Looking like Figma buys nothing; behaving like Figma, so that the shortcuts work and the panels are where the hand expects, buys everything. The test is whether a proficient user of the original is immediately proficient in yours, without being told anything.

Three separate assets come with it, in increasing order of value and difficulty.

Muscle memory. The cheapest to acquire and the most visible. Shortcuts, panel positions, the meaning of a right-click. This alone removes most of a learning curve.

The ecosystem. Extensions, plugins, themes, templates, and the accumulated answers on forums. Cursor inherited most of the VS Code extension ecosystem without writing any of it, which is worth more than the interface.¹ Not all of it: Microsoft’s own extensions are licensed to its own builds, so a fork gets the open registry and not the proprietary parts. Even a partial inheritance beats starting from nothing.

Decisions already made. The least discussed and the most valuable to a small team. Every interaction the incumbent settled is one you do not have to argue about, prototype, or get wrong, and none of it has to be revealed gradually because the user already knows it is there. A startup competing on a single differentiator can spend all of its design attention on that differentiator, which is the actual reason this pattern wins.

One precondition sits underneath all of it. Cursor could fork Visual Studio Code because VS Code is released under a permissive license; forking is a legal act before it is a product decision, and the look and feel of an interface can itself be legally protected. Check what you are allowed to copy before you plan a strategy on copying it.

The loan comes due

Everything above is borrowed, and the repayment is a permanent constraint on what you can become.

You inherit the incumbent’s mistakes along with its conventions. Every awkward decision baked into the original is now baked into yours, and departing from it costs you the familiarity you built the strategy on.

Your differentiator has to fit inside the borrowed shell. This is the real constraint and it decides whether the pattern is available to you at all. AI-assisted editing fits inside a code editor, because suggesting and accepting text is what a code editor already does. An innovation that requires a fundamentally different interaction model cannot be delivered this way, and trying produces a product at war with its own interface.

Familiarity is not a reason to switch. It removes the reason not to, which is a different job. “It is just like the thing you use” gets a trial; it never gets a migration. Products that clone well and differentiate weakly end up as a slightly better version of something people already have, which is the least defensible position in software and shows up first in retention.

The formulation worth keeping: borrowing an interface lowers the cost of trying you. It does nothing at all for the reason to try you, and those have to be solved separately.

What it does give you is an unusually well-defined audience. Every user of the tool you borrowed from is pre-trained and pre-qualified, which means you know exactly where to market and what the pitch is: it is the thing you already use, plus the one difference. That sentence spreads between users of the original without your involvement, and it is the cheapest distribution this pattern offers.

When there is nothing to borrow

The pattern needs a dominant tool that your users genuinely share, and that condition is rarer than it looks.

Before concluding it is unavailable, note the lighter version, which needs no fork and no shared interface: borrow the concepts rather than the pixels. A product whose objects are issues, projects and cycles speaks a vocabulary its users already think in, even with nothing about the layout copied. That is available in almost any category, because a shared vocabulary is far more common than a shared tool.

The stricter version does need a dominant tool. If your users come from four different backgrounds with four different incumbents, there is no single interface to inherit, and picking one alienates the other three. If the category has no dominant tool, there is no muscle memory in the market to capture. And if your users are new to the category entirely, there is nothing to be familiar with, and your job is to be obvious, not familiar, which is harder and more valuable.

The categories where it does work are recognizable: code editors, where a generation of tools (Cursor, Windsurf) forked or mimicked the same editor; developer platforms positioned explicitly as the open alternative to a named incumbent, where the borrowed thing is the category’s mental model, not its API; and project tooling that adopts the vocabulary its users already argue in (Linear). What they share is a market where one tool, or one shared way of talking, trained everybody.

The adjacent-use-case version is easier and underrated: if you look like a tool people already love but solve a job it does not, you are an addition to their toolkit, not a migration, and nobody has to be talked out of anything. Framer, which took the conventions of modern design tools into website building, is the clearest instance: its users were not asked to abandon anything.

It is worth naming the opposite strategy, because it also works. Superhuman built a deliberately unfamiliar email client, keyboard-driven and fast, and then taught it, by the widely repeated account, person by person over an onboarding call. That is the trade in the other direction: a steeper curve in exchange for an interface that is genuinely better rather than merely recognizable. It is more expensive and it does not scale the same way, and it is the right choice when your advantage cannot fit inside somebody else’s shell.

What borrowed familiarity should buy you?

The claim to test is that people from the incumbent behave differently, and every version of that is an internal comparison.

1. Do users who arrive from the tool you cloned activate faster than users who do not? If the gap is small, the resemblance is cosmetic, not functional, and the shortcuts probably do not all work.
2. What share of new users import their existing configuration, if you allow it, and do they retain better? This is the strongest available signal that inheritance rather than imitation is happening.
3. How many support questions are about the interface versus about your differentiator? In a working version of this pattern, almost none are about the interface. A rising share of interface questions means you have drifted from the original in ways users notice and did not want.

Before you clone anything

1. Name the one tool your users already know, and be honest about what share of them know it. If the answer is under half your market, this pattern is not yours.
2. Recruit five heavy users of the tool you borrowed from and watch them work. Not a survey. Watch where their hands go and where the product punishes them for it. Five sessions will find more than any amount of analytics, because the whole thesis is about reflexes and reflexes are only visible in use.
3. Test the shortcuts, all of them. Partial fidelity is the worst outcome available: it teaches users to trust their reflexes and then punishes them for it, which feels worse than an unfamiliar product.
4. Let people bring their configuration across. Frequently skipped, and it is what separates inheritance from imitation.
5. Write down your differentiator in one sentence, then check that it can be delivered without breaking the interface you borrowed. If it cannot, you have to choose, and choosing early is much cheaper.
6. Remember that execution can be the whole differentiator. Being materially faster or more polished than the incumbent, with no new concepts at all, is a legitimate and often underrated answer to “why switch.”
7. Ship nothing that breaks a reflex without deciding it is worth the cost. Similarity is the removal of an objection. Put your roadmap into the thing that is genuinely better, because that is the only part anybody switches for.

That closes the question of the first session. Everything in this section is about a stranger reaching value once: given something to hold, routed to the right place, shown what goes on an empty screen, allowed to experiment safely, or handed an interface they already knew. All of it can succeed and still produce nothing, because a user who got value once and never came back is a user you spent money to entertain. What turns a first session into a second one is a different discipline entirely, and for most products it starts somewhere unglamorous: not persuading anyone to come back, but arranging things so they never have to remember to.

Updated August 2026