Build · founder · 6 min read

Figma Bought Bud (Orchids) and Is Shutting It Down July 18. What Builders Should Do.

Figma acquired the Bud/Orchids vibe-coding team and is sunsetting both apps by July 18, 2026. Here's the migration playbook and the real lesson.

On July 7, Figma acquired the team behind Bud — the vibe-coding and AI-agent platform formerly known as Orchids. That’s normal 2026 consolidation news, except for one line in the announcement that matters if you’re a user: both Bud and Orchids shut down on July 18, 2026, and you have to migrate your projects out before then.

That’s an eleven-day window. If you built anything on either product, this guide is the short version of what to do, followed by the part that matters more — what this keeps teaching us about building on someone else’s platform.

What happened

Bud started life as Orchids, a Y Combinator-backed vibe-coding platform that let people spin up apps for mobile, web, Slack, and the browser from natural-language prompts. It later pivoted and rebranded to Bud, an agent platform that could browse the web, call services, and write code to automate tasks. Figma bought the team — an acquihire, in effect — to pull the “coding and prototyping layer” closer to its canvas, the same direction it’s been pushing with Figma Make, its Codex and Claude Code integrations, and its own on-canvas agents.

Two things worth naming honestly. First, this is a talent-and-technology deal, not a commitment to keep the product running — hence the fast sunset. Second, Orchids had a rough security moment earlier this year: the BBC reported, citing a security researcher, that apps built on Orchids were exposed to attacks. That’s context, not the headline, but it’s relevant if you shipped an Orchids-built app to real users.

If you built on Bud or Orchids: the 11-day checklist

Assume nothing survives July 18. Move fast, in this order.

Export your code and assets first. Pull down every project’s source, database schema, environment variables, and any uploaded assets. If the export gives you a working repo, get it into your own GitHub or GitLab today. If it only gives you a partial export, screen-record the app behavior and copy out the prompts and configuration so you can rebuild.

Inventory what’s actually live. List anything that real users or customers touch — a deployed app, a Slack agent, an automation wired into your business. Those are your priorities. Prototypes and abandoned experiments can be triaged or abandoned.

Move deployments you depend on. If Bud was hosting a live app, it goes down with the platform. Redeploy anywhere you control — Vercel, Netlify, Cloudflare Pages, Railway — before the 18th, not on the 18th. Update any DNS and webhooks pointing at Bud-hosted URLs.

Rotate your secrets. Any API keys, OAuth tokens, or database credentials that lived inside Bud or Orchids should be rotated once you’re off the platform. Given Orchids’ earlier exposure report, treat this as non-optional for anything customer-facing.

Pick a landing spot. For most people reading this, the natural migration targets are the full-stack builders we cover — Lovable, Bolt, Replit, or Base44 — or, if you’ve got some technical help, Cursor or Claude Code on your exported repo. If your app was mostly a prototype, this is a chance to rebuild it cleaner on a platform you trust to still exist next quarter.

The lesson that keeps repeating

This is the third or fourth time in a few months we’ve written some version of the same sentence: a vibe-coding tool got absorbed, and its users had to scramble. Windsurf became Devin Desktop. Cursor got acquired by SpaceX. Now Bud/Orchids is being switched off entirely with under two weeks’ notice. Consolidation in this space isn’t a risk anymore — it’s the base rate.

The takeaway isn’t “don’t use young platforms.” Early tools are often the best tools, and waiting for everything to be safe means never shipping. The takeaway is to build so that a platform disappearing is an inconvenience, not an extinction event.

Three habits that make acquisitions survivable

Own your code and your data, continuously. The single biggest difference between the founders who shrug at news like this and the ones who panic is whether they can export a working repo and a database dump on any given day. If your tool doesn’t let you get your code out, that’s not a minor limitation — it’s the whole risk, concentrated. Check that export path before you commit, and pull a backup on a schedule.

Keep your integrations loosely coupled. Point customers at a domain you own, not a platform-generated URL. Keep secrets in a manager you control. Route critical automations through pieces you can re-wire. The more of your stack that lives inside one vendor, the more of your stack leaves when that vendor does.

Match the platform to the stakes. A weekend prototype can live anywhere — who cares if it vanishes. A live app with paying customers deserves a platform you’d bet a quarter of runway on, and a documented plan for getting off it. We wrote a fuller version of this in our guide to picking AI tools that last and the defensibility audit for vibe-coded startups — both worth ten minutes if this news made your stomach drop.

Bottom line

If you’re a Bud or Orchids user, the only urgent thing is the calendar: export everything, redeploy anything live, rotate your secrets, and be fully off by July 18. If you’re not, use this as a free rehearsal. Open whatever tool you’re building on right now and answer one question — if this shut down in eleven days, could I get my code, my data, and my live app out in time? If the answer is no, that’s the thing to fix this week, regardless of what happens to any single platform.

Related guides

Recommended next step

Was this helpful?