The idea and why it works

Most software is bought twice. First one person signs up, does real work on their own, and pays a small amount. Later their company buys a team plan, often for a different tool, because the first one never gave the solo user an easy way to bring colleagues into the work they had already done. The personal-to-team move is a growth play that closes that gap: when a solo user creates or joins a team, you let them carry their existing work across in a click, with its history intact, so the team starts with something useful on day one instead of an empty screen.

The clearest current example is v0, Vercel's AI app builder. v0's Teams documentation (last updated 2 November 2026) says you can transfer chats "between any of your available scopes, either team or personal". One chat moves from its header menu with "Transfer Chat"; many move at once through Settings, Workspace, "Transfer Data". If a chat is linked to a Vercel project, the project travels with it when you own the project's current team. After the move, team owners can see the chat's full history, including messages written before the transfer. The billing follows the same logic: each seat includes $30 of monthly credits that roll over for one month, and a Shared Credit Pool that the whole team draws from once individual credits run out.

The v0 changelog shows the pieces arriving over the year: a "Transfer Chats" option after account upgrade (25 February 2026), team chats visible to the team by default (10 September 2026), and, on 6 October 2026, "Personal v0 accounts are now team workspaces". It says migrated accounts kept their chats, projects and settings.

Why does this work as growth? Two reasons. The person most likely to bring in a team is your heaviest solo user, and the thing stopping them is usually rework: re-creating projects, re-explaining context, re-uploading files. Remove the rework and the invite becomes cheap. Second, the transferred history becomes the team's onboarding. A new colleague opens a chat and sees how the work got where it is, which is far more persuasive than a welcome tour. This is the single-player-to-multiplayer progression: the product is useful alone, then more useful with others, and the bridge between the two costs the user nothing.

Who it's for

This suits any product where one person builds up valuable work over time and that work is naturally shared later: AI builders and writing tools, design and diagram apps, research notebooks, client portals, analytics dashboards, prompt libraries and template tools. It fits solo founders whose buyers are freelancers today and small agencies tomorrow. It matters less if your product holds nothing worth keeping (a one-off converter, say) or if every account is already a company account from the first day.

What you need

  • Tools: a data model where each item (project, chat, document) has an owner that can be either a person or a workspace. If you already have workspaces, you mostly need a "change owner" action that keeps the item's ID, history and links.

  • Time: for a small app with a clean schema, roughly one to two weeks of build for single-item transfer, plus a few days for bulk transfer and the prompts. This is an estimate; it grows if files, integrations or billing are tangled with the user record.

  • Cost: engineering time only. If you sell credits, decide whether personal credits stay personal (v0's approach) or move with the user.

Step-by-step

  1. Make ownership movable. Store an owner type and owner ID on every item instead of a user ID. A transfer should be a single update to that field, never a copy. Copies create duplicate history, broken links and confusion about which version is real.

  2. Decide what travels. List everything attached to an item: history, comments, files, connected integrations, share links, scheduled jobs. Mark each as moves, stays, or needs reconnecting. v0's rule for linked projects (they move only if you own the project's current team) is a good model for an explicit, permission-based rule.

  3. Offer one-item and bulk transfer. A per-item "Move to team" action handles the occasional case. A bulk screen with checkboxes, filters by date or folder, and a preview of what will move handles the day someone sets up a team. v0 offers both.

  4. Prompt at the moment of upgrade. Right after someone creates a team or accepts an invite, show the transfer screen. v0 added a "Transfer Chats" option after account upgrade for this reason. A second prompt fits when a solo user shares the same item with the same colleague a few times.

  5. Set a sensible default visibility. Decide whether moved and new items are private, team-viewable or team-editable, and let the workspace owner change it. v0 makes new team chats visible to the team by default, with owners able to choose Private, Team can view or Team can edit.

  6. Make billing follow the team. Give each seat its own allowance, add a shared pool the team can top up, and say clearly which is spent first. v0 spends individual monthly credits before the Shared Credit Pool. A short rollover softens the fear of losing unused credits when someone switches plans.

  7. Keep a way back. Allow items to be moved back to personal, at least within a grace period, and keep a log of who moved what and when. People commit faster when a mistake is reversible.

Template: the in-product prompt and transfer flow

Here is copy you can adapt. Keep it short and specific about what stays the same.

Prompt after a team is created: "Bring your work into Acme Studio? You have 14 projects in your personal space. Move the ones you want and your team will see them with their full history. Nothing is rebuilt and links keep working. [Choose projects] [Not now]"

Prompt after repeated sharing: "You've shared 'Pricing page' with Sam three times this month. Move it to your team space so Sam can edit without asking? [Move to team] [Keep personal]"

Confirmation screen: "Moving 6 projects to Acme Studio. What moves: history, comments, files. What needs reconnecting: your Google Drive link on 2 projects. Visibility: Team can view (change). You can move them back within 30 days."

Success message: "Done. 6 projects are now in Acme Studio. Invite teammates to see them."

The success message points straight to the invite, because a moved project with no one else in the room delivers half its value.

Test it from the user's side

Before you ship, ask whether moving their work gives the solo user something real. Three checks matter. Do they avoid rebuilding? Do they keep history, so the context that made the work valuable comes along? Does billing get simpler, with one shared pool instead of personal cards? If the answer to any is no, the prompt feels like a sales tactic.

Notion shows the trade-off clearly. Its guide to moving content between workspaces says content is duplicated into the destination, and that links, relations, permissions and page history may break; it recommends keeping the originals until you are sure the copy is right. That is honest guidance for a hard problem across separate workspaces, and it shows why a move inside one account, keeping the same item, is easier for users to trust. Figma's drafts update took a different route: it moved drafts into teams, each team with its own drafts space, and its move-a-file guide warns that moving a file "may change who has access to it". Spell out permission changes like this on your confirmation screen.

Illustrative maths, not a result

No company has published verified uplift numbers for this play that we could find, so here is a model you can replace with your own figures. Say you have 1,000 paying solo users at $20 a month. Suppose 15% of them regularly share work with someone else, which gives 150 people. If the transfer prompt turns one in five of those into a two-seat team, that is 30 teams, adding 30 extra seats, or $600 a month. Every input here is an assumption. The point is to see which number matters most: the share of solo users who already collaborate. Measure that first.

Metrics to watch

  • Prompt-to-transfer rate: of users shown the prompt, how many move at least one item.

  • Items moved per transfer: one item suggests a trial; many suggest commitment.

  • Invite rate after transfer: share of transfers followed by an invite within seven days.

  • Teammate activation: share of invitees who open or edit a moved item in their first week.

  • Seat expansion and retention: seats per team at 30 and 90 days, and churn of teams compared with solo accounts.

  • Move-back rate and support tickets: a high rate signals confusing permissions or missing data.

Pitfalls

  • Silent permission changes. If a private item becomes visible to the whole team without warning, trust drops fast. Show visibility on the confirmation screen.

  • Broken links and integrations. Test share links, embeds and connected accounts after a move. List anything that needs reconnecting.

  • Losing credits or paid features. If a move or a plan change wipes someone's unused balance, they will hold back. A short rollover, as v0 offers, removes that worry.

  • Prompting too early. Asking a two-day-old user to "bring your team" is noise. Wait for a signal: a team created, an invite accepted, or repeated sharing.

  • Ownership after someone leaves. Decide what happens to moved items when the original creator leaves the team, and say so in your help pages.

Variations

  • Automatic workspace by default: make every personal account a one-person workspace from the start, as v0 did in October, so the "transfer" is just inviting someone in.

  • Client handover: freelancers build in their own space, then move the finished project into the client's workspace as part of delivery.

  • Carry the anonymous session too: extend the same rule earlier in the journey, so work done before sign-up lands in the new account, as we covered in anonymous first task.

  • Pair it with a loop: moved, shared items are good places for a "Made with" badge, and a shared pool pairs well with a credits programme for power users.

Sources

Comments

Avatar

or to participate