# Else — Full text index Canonical site: https://www.somethingelse.ai Last updated: 2026-05-21T18:05:54.431Z > Else is an AI prototyping platform that lets product managers and designers build working prototypes directly on their real product codebase, test with real users, and hand engineers a production-ready pull request. Full index: https://www.somethingelse.ai/llms.txt --- ## / Source: https://www.somethingelse.ai/ Published: 2026-04-27 # Idea → Prototype → Ready-to-ship PR All without writing a line of code. You know what needs to change. You’ve designed it, validated the concept, maybe even built a Figma prototype that everyone loved. Then it goes into the backlog. Then it waits. Else fixes that. Else lets product managers and designers prototype directly on your real product, test with real users, and hand engineers a production-ready PR. No throwaway Figma files. No waiting for a sprint slot. No “we’ll get to it.” --- ## Proof 90% faster to production. PRs merged with zero changes. > “With Else, we went from validated prototype to production PR in a fraction of the time it used to take. Engineering didn’t touch it until it was ready to merge.” > — Drew Muller, Ferry International --- ## From zero to live ### Prototype Build directly on your real product. **Prototype on your actual product — not a copy of it.** Static mockups lie. They don’t have your real data, your real components, or your real edge cases. Else runs inside your live product, so what you’re testing is exactly what your users will see. No more “it looked different in Figma.” **Build working features** There are no limits with Else. A single prototype can live across multiple pages and completely rework UX and backend interactions. **Match your design system** Else learns from your codebase to inherit your design system and re-use existing components. It just works. **Full stack** Want to add new backend functionality? Else extends your backend without modifying it, including a new data layer. ### Launch What you built is what ships. **Ship what works** Ship what works, rework what doesn’t. Improve your KPIs while keeping your product free from the bloat and carry cost of unused features. **Hand over a PR, not a brief.** When your prototype works, Else opens a frontend PR ready for engineering review. The polish you got right stays right. For new backend functionality, you get a full spec and an integration prompt. Engineering’s job becomes: review, test, merge. No more starting from scratch. No more losing the details in translation. **Full backend spec** Export a full spec for new backend functionality, along with a prompt to integrate it in your real backend. **Prototype to production in a jiffy** With a ready PR and a clearly defined target, your engineering team can ship to production fast. --- ## How it works **Step 1 — Prototype** - Install the Else GitHub app on your frontend repo - Answer a few questions - Done! Start hacking on top of your product. **Step 2 — Live user test** - Integrate our lightweight client SDK - Set up server-to-server integration - Done! Run live user tests with zero engineering involvement. --- ## FAQ **What tech stacks does Else work with?** Else works with any backend technology, and with any client-rendered SPA frontend. This includes most React, Angular, Vue, etc. **How technical do I need to be to build with Else?** Else works the same as most vibe coding environments. It helps to have some technical understanding but you don’t need to know how to code. **How does Else run inside our product?** The Else client SDK loads a different version of your product, hosted by Else, when an experiment runs. In normal cases the Else SDK does nothing. **Can I test before integrating?** Yes. Else needs to be added to your frontend repo before you can start prototyping. Else supports GitHub, GitLab, and Bitbucket. **What level of access does Else require?** Else needs access to your frontend repo, but not your backend. Else works best if you can provide an OpenAPI spec for your backend. --- ## Don’t fill the backlog with tickets you can implement yourself. Build with Else. Schedule a demo or get on the waitlist at https://www.somethingelse.ai/ --- ## /architecture Source: https://www.somethingelse.ai/architecture Published: 2026-04-27 # Architecture Learn how Else integrates with your infrastructure while keeping prototypes isolated and secure. --- ## Product Overview Else spins up isolated cloud workspaces that run your front-end code, configured to solve limitations like CORS and SSO. Your workspace connects to your staging API (or production, if you prefer), so authentication, data, and business logic all work exactly as they would in your real app. An AI agent helps you iterate on new features. If new backend functionality is needed, Else creates an extension backend with its own database. The extension backend allows adding and augmenting endpoints to layer on additional functionality. When you’re done prototyping, Else creates a clean pull request with just the front-end changes. You can also optionally publish prototypes to show them to specific users in your live product using the Else SDK, without having to deploy through your own infrastructure. --- ## Core Components Else has a few core components that work together to enable prototyping and live previews. **Else Portal** The homepage/dashboard used for administration, product configuration, and launching workspaces and prototypes. **Workspaces** Isolated machines spun up on demand to run your front-end inside the Else Development Environment. **Else SDK (optional)** A client-side bundle loader used to render published prototypes inside your live product for targeted previews and experiments. **Else API (optional)** A control plane used to load preview/experiment bundles for the Else SDK; it is not required for running workspaces. --- ## Product Setup Product configuration has two steps: create a product, and configure the workspace so your app runs cleanly in Else. **Step 1 — Connect your Product** - Install the Else GitHub app on your frontend repo - Link your repo and select the base branch to prototype from - Provide the URL of your backend (typically staging API) - Optionally add backend documentation (OpenAPI/Swagger endpoint) **Step 2 — Configure a Baseline Workspace** - Else launches a workspace with a setup agent - Agent auto-detects package manager, dependencies, etc. - Agent may make code changes (not included in PRs from Else) - Iterate until the front-end is fully functional inside the workspace --- ## Else Workspaces A workspace is a single externally reachable URL backed by a reverse proxy that routes to multiple internal services. **App Preview** — Your front-end dev server **Else Dev Environment** — The UI for iteration and tooling **Workspace Daemon** — WebSockets + APIs for the agent **Extension Backend** — Optional Deno service ### Origin API Communication Workspaces run your front-end against your existing backend (usually staging). Requests are routed through the workspace proxy so browser sessions behave normally (cookies, auth redirects) and you avoid local CORS issues. ### Extension Backend If a prototype needs new backend behavior, Else runs an extension backend alongside your frontend. It acts as a programmable middleware layer, adding or transforming endpoints while forwarding to your real API. --- ## Publishing to your Live App Publishing is separate from the Git/PR workflow. It exists so you can load a prototype inside your live product without deploying through your own infrastructure. Optional: skip if you only need workspaces + PRs. **Else SDK** A small client-side bundle loader that can swap your app’s default SPA bundle for a published prototype bundle. Has no impact on users who aren’t configured to see an Else prototype. **Bundle Selection** Your app decides when to load a prototype (e.g., user is in a target cohort) and sets the prototype bundle URL via the SDK. **Else API** When using the Else SDK, you must integrate with the Else API to determine what user sees what prototype. --- ## Security & Data Flow Else is designed to minimize required access and keep clear boundaries. **Code Access** Else requires access to your front-end code to build and run prototypes. Else does not require access to your backend code. **Data Access** Else does not require direct access to your database or production data. Workspaces typically run against your own staging environment. **Data Flow** For standard prototypes, your browser talks directly to your API as usual via the workspace proxy. If you enable an extension backend, some traffic may flow through that extension service. **Data Persistence** Raw request/response data is never persisted. Else may store anonymized metadata about the shape of requests/responses inside the workspace to improve agent performance. **Isolation & Credentials** Each workspace is isolated, and access is gated by scoped auth tokens/API keys. The agent the user interacts with is sandboxed with limited access. Your code is only accessed by a dedicated Else machine without public access, and by your isolated workspaces. --- ## /resources/comparisons/else-vs-figma-make Source: https://www.somethingelse.ai/resources/comparisons/else-vs-figma-make Published: 2026-04-27

For the PM on an existing product whose work has to ship as code, not as a Figma artifact.

Figma Make pushes to GitHub one-way – the React it generates lands on your default branch, no PR, no review gate. The code follows Figma’s idea of your design system (the library, the Variables, now Make kits) rather than the React your team actually writes. Engineering opens the repo, finds code it didn’t review, and starts reconciling it against what already ships. Else writes against the codebase from the first prompt and opens a PR engineering reviews like any other change – so the design system the prototype uses is the one already in production, not the one packaged in a Figma kit.

## TL;DR Figma Make turns a Figma design and a prompt into a working React prototype, published as a web app with a public URL or embedded inside Figma, with an optional one-way push to a GitHub default branch. Figma Make is at its sharpest when the team’s design system already lives in Figma—Variables wired up, components published in libraries, and now (April 2026) Make kits packaging design tokens and npm components for the prompt to inherit. Else removes the design-to-engineering translation step. Else writes the prototype directly against the customer’s real frontend codebase across React, Vue, and Angular, inheriting the components, CSS, and design system already in production. The prototype runs against the customer’s staging backend and deploys inside the actual product for real user tests, then lands as a pull request engineering reviews on GitHub, GitLab, or Bitbucket — code already written in the team’s stack, not generated React the team has to re-fit. --- Both Else and Figma Make turn an AI prompt into something interactive. Figma Make produces a high-fidelity interactive prototype generated from a Figma design. Else produces a working feature on the customer’s real product code, against the real backend, in the team’s existing stack. Else is built for product managers and designers who need the prototype to land as a pull request engineering can review, test, and merge—on the codebase that already exists, in the framework that already runs. ## The honest split Figma Make is at its sharpest as a Figma-native prototyping tool: a designer prompts a design file into a working React prototype that publishes inside the Figma ecosystem. The Make kits release in April 2026 closed the design-system-context gap that earlier versions had. Else is built for different ground entirely. The prototype runs on the customer’s real frontend code from the first prompt, across React, Vue, and Angular, on GitHub, GitLab, or Bitbucket, against the customer’s staging backend, and lands as a pull request engineering reviews—not a one-way push to a single default branch. ## Side by side | | Figma Make | Else | |---|---|---| | Who’s at the keyboard | Designer or PM (design-file-centric workflow) | Product manager, designer (repo-centric workflow) | | Frontend frameworks | React only | React, Vue, Angular—any client-rendered SPA | | Repo platforms | GitHub (default branch push only) | GitHub, GitLab, Bitbucket | | Design system handling | Figma library + Make kits; design system canonical state is Figma | Inherits the design system already in the customer’s codebase | | Backend | Optional Supabase connection; mock backend otherwise | Runs against the customer’s staging backend | | Live user testing | Figma Sites or embedded prototype; no in-product analytics | Targeted in-product deployments to real users in the actual product | | Output | Code pushed to GitHub or published interactive prototype | Pull request to GitHub, GitLab, or Bitbucket | | Multi-framework per customer | One framework per Make | Multiple frameworks under a single customer | ## Where Figma Make wins Figma Make is at its sharpest as a designer’s tool inside Figma. For a designer whose design system already lives in Figma — Variables wired up, components published in libraries, Make kits packaging the design library — Figma Make turns a design file into a high-fidelity interactive prototype without leaving Figma, with mobile preview from the Figma app and embed support across Figma design files, FigJam, and Slides. When the goal is an interactive Figma artifact for stakeholder review, Figma Make is the shortest path. ## Runs on the real product code, not the design file Else writes against the existing frontend code from the first prompt — the actual components engineering already shipped, the actual CSS already in the repo, the actual routing already in production. The prototype and the product are the same codebase, not two artifacts that have to be reconciled later. The prototype looks like the product because it is built from the product. Figma Make generates code from a Figma design and pushes the result to a GitHub repo as new code in Figma Make’s own component patterns. Engineering still has a translation pass to align that code with the production stack. ## Inherits the design system already in your product Else builds the prototype out of what the product already uses. Components, CSS tokens, typography, spacing — Else writes against the design system that already ships in the codebase, not a separate library to maintain in parallel. Figma Make brings design-system context from a Figma library or a Make kit npm package — useful when the source of truth lives in Figma. The design system most B2B SaaS teams ship on lives in code, not in Figma; Else writes against that code directly. ## Lands as code already written in your stack Else writes the prototype directly against the team’s existing codebase, so what arrives in the pull request is non-opinionated code already written in the team’s stack — feature branch, diff, review, merge — the same workflow engineering already runs. Figma Make pushes generated React to the GitHub default branch when an export is requested. The code is opinionated, written in Figma Make’s component patterns rather than against the team’s existing components, design tokens, or conventions, so engineering still has a translation step before that code can ship inside the product. ## Runs on the codebase, regardless of stack Else supports any client-rendered SPA: React, Vue, and Angular. The PM at a Vue shop and the PM at a React shop use the same Else, on the same workflow, against the same kind of pull request output. Figma Make’s code output is React. A team running on Vue or Angular cannot use Figma Make to generate code on their existing codebase — the framework is not supported. ## Ships across GitHub, GitLab, and Bitbucket Else opens pull requests on GitHub, GitLab, and Bitbucket. A team running engineering on GitLab or Bitbucket does not need to migrate, mirror, or stand up a parallel GitHub presence to use Else. Figma Make pushes to GitHub only, and only to the default branch. Teams on GitLab or Bitbucket have no path into the repo. ## Runs prototypes inside the actual product Else deploys the prototype inside the customer’s actual product, served to specific users, teams, or companies through a targeted deployment via the Else SDK. A real user logs into the real product on a real account and sees the prototype as part of the experience; everyone else sees production. That makes user testing a test of the actual change in the actual environment, not a test of an embedded artifact. Figma Make publishes the prototype as an interactive web app with a public URL or embeds it in a Figma design file, FigJam, or Slides — useful for stakeholder review inside the Figma ecosystem, not for testing the change inside the product the customer ships. ## When to pick Figma Make A designer with a design system already in Figma, building an interactive prototype to share with stakeholders or take into a design review — that is Figma Make’s room. Make kits bring the design library as context, mobile preview lets the designer test on a real device, and the prototype lives where the rest of the design work already lives. If the goal is an interactive Figma artifact rather than a PR engineering reviews, Figma Make is built for that. ## When to pick Else A PM or designer with a product already in market—real codebase, real design system in code, real backend, real users—whose work has to ship as code engineering can merge, not as a Figma artifact with a public URL. The prototype has to look like an embedded part of the app the team already ships, span more than React, reach beyond a one-way push to GitHub, and land as a reviewable PR on the repo they already use. The reason to pick Else is the work where the prototype is not the destination—the merged PR is. ## FAQ ### Does Else write code engineering can merge without a translation step? Yes. Else writes the prototype directly against the team’s existing codebase, so what arrives in the pull request is non-opinionated code already in the team’s stack — components, design tokens, and conventions intact. Figma Make pushes generated React to the GitHub default branch in its own component patterns, which engineering still has to translate before the code can ship inside the product. ### Does Else work with Vue and Angular codebases? Yes. Else runs on any client-rendered SPA, including React, Vue, and Angular. The prototype is generated against the customer’s existing codebase, with no port and no rebuild between the prototype and the production framework. Figma Make outputs React only. ### How does Else handle our existing design system? Else builds the prototype out of the components, CSS tokens, and typography already in the customer’s codebase. The output looks like the product because it is built from the product. Figma Make brings design-system context from a Figma library or a Make kit npm package; Else reads the design system that already lives in code. ### Can a product manager or designer use Else without an engineer? Yes. Else is built around the assumption that the person at the keyboard is a product manager or a designer, not an engineer. The prompt design, repo permissions model, and deployment workflow all sit in front of a non-technical user. Engineering enters the workflow on the pull request, not before it. Figma Make also serves designers and PMs but the workflow centers on Figma; Else’s workflow centers on the customer’s repo, with the prototype landing as a pull request engineering reviews. ### Does Else replace Figma Make? No. Figma Make is built for designers and PMs whose design system already lives in Figma and whose goal is a high-fidelity interactive prototype to share inside the Figma ecosystem. Else is a prototyping environment for product managers and designers who want the prototype to ship into the product they already run — across multiple frameworks, repo platforms, and the actual product itself. The two tools sit in different slots and can be used by different people on the same team. --- ## /resources/comparisons/else-vs-lovable Source: https://www.somethingelse.ai/resources/comparisons/else-vs-lovable Published: 2026-04-24

For the PM on an existing product who wants to prototype without rebuild risk.

Both tools turn a prompt into a working prototype. The question is: where does the prototype live, and what happens next? Engineering loved the design, hated the code. They rebuilt it on your real codebase, matched it to your design system, tested it against your backend. A full rework and weeks later. Else puts the prototype on the real codebase from the start—so engineering reviews code, not a design brief.

## TL;DR Lovable generates React and Vite projects on GitHub, with Lovable Cloud as the default backend and an autonomous AI agent as the primary actor. Lovable is at its sharpest for engineers and PMs starting from zero—a founder validating an idea, a team building a standalone demo, someone exploring a concept without pulling engineering into the loop. Else runs on a customer’s real frontend codebase across React, Vue, and Angular, on GitHub, GitLab, or Bitbucket. Else inherits the existing design system, runs against the customer’s staging backend, and deploys prototypes inside the actual product for real user tests. Else is built for product managers and designers working on the codebase that already exists. --- Both Else and Lovable turn an AI prompt into a working prototype. The difference is what the prototype is built on, which platform you ship it to, what design system it inherits, and where the test happens. Else is built for product managers and designers who need the prototype to live inside the product they already ship, on the codebase that already runs, landing as a pull request engineering reviews. ## The honest split Lovable is at its sharpest as a zero-to-working-app tool—a founder validating an idea, a PM building a standalone demo, a designer exploring a concept without pulling engineering in. Agent Mode and Lovable Cloud compress the path from prompt to working app. Else covers that same prompt-to-prototype ground, then keeps going: across React, Vue, and Angular, across GitHub, GitLab, and Bitbucket, on the design system already living in the customer’s codebase, against the customer’s staging backend, and landing as a pull request engineering reviews on the repo they already use. ## Side by side | | Lovable | Else | |---|---|---| | Who’s at the keyboard | AI agent (user in chat); user can edit code directly in dev-mode | Product managers, designers | | Frontend frameworks | React + Vite + TypeScript — React only. Vue and Angular teams have no path with Lovable. Multiframework teams are forced to pick one stack or run two tools in parallel. | React, Vue, Angular—any client-rendered SPA. One Else account covers all stacks. | | Repo platforms | GitHub | GitHub, GitLab, Bitbucket | | Design system handling | Connected design-system project; generates code to match rules in `.lovable/rules/` | Inherits the design system already in the customer’s codebase | | Backend | Lovable Cloud (Supabase native), Supabase, Edge Functions, or custom REST/GraphQL | Runs against the customer’s staging backend | | Live user testing | Browser-test agent in virtual browser; preview deploy to Lovable Cloud, Netlify, or Vercel | Targeted in-product deployments to real users in the actual product | | Output | GitHub PR via `lovable` branch, or zip download | GitHub, GitLab, or Bitbucket pull request | | Multi-framework per customer | No; one project is React | Multiple frameworks under a single customer | ## Where Lovable wins Lovable is at its sharpest as a 0→1 builder. For a founder validating a new product idea, a PM building a 0→1 working demo for a stakeholder meeting, or a designer exploring a concept without pulling engineering in, Lovable Cloud bundles the backend (Supabase native), the database, and the deploy into one pass — there is no infrastructure to stand up before the first prototype is live. Agent Mode runs the build end-to-end without needing the user in the loop for each decision. When the work is a new app from a blank prompt, Lovable is the shortest path. ## Inherits the design system already in your product Else builds the prototype out of what the product already uses. Components, CSS tokens, typography, spacing, the buttons engineering already styled, the modal pattern that already ships—Else writes against those rather than generating its own. Lovable expects a separate design-system project, with rules stored in `.lovable/rules/` that the agent reads during generation. Else reads from the codebase you already have; there is no separate artifact to maintain. For the PM-side experience of that gap — what it costs to rebuild a design system inside Lovable every session — see the [design-system recreation tax](/resources/field-notes/design-system-recreation-tax). ## Built for product managers and designers in the loop Else is built around the assumption that the person at the keyboard is a product manager or a designer, not an engineer. The interface, the prompt design, the repo permissions model, and the deployment workflow all sit in front of a person who knows what should change about the product but is not writing the production code. Lovable’s Agent Mode runs end-to-end without the user at each step. The user types a prompt and the agent executes the full build cycle. That autonomy is powerful for a founder building a brand-new app; it is a different contract for a PM at a company where engineering owns the codebase and the PR review is non-negotiable. The two tools are made for different people doing related but distinct work. ## Runs on the codebase, regardless of stack Else writes against the code already in the customer’s repo — same components, same patterns, same conventions, same framework. The output looks like the rest of the codebase because it is written into the rest of the codebase. There is no separate stack to reconcile and no opinionated rewrite for engineering to translate. Lovable generates in its own opinionated stack: React + Vite + TypeScript, in Lovable’s component patterns and conventions. A team on Vue or Angular has no path. A team on React has a path that still ends in code engineering would have to rewrap to fit the patterns the rest of the app uses. ## Ships across GitHub, GitLab, and Bitbucket Else opens pull requests on GitHub, GitLab, and Bitbucket. A customer running engineering on GitLab or Bitbucket does not need to migrate, mirror, or stand up a parallel GitHub presence to use Else. Lovable is GitHub-only. For teams whose primary repo platform is GitLab or Bitbucket, Lovable has no path into the repo. The prototype-to-PR workflow only works if the prototype tool ships to the platform engineering already lives on. ## Runs prototypes inside the actual product Else deploys prototypes inside the customer’s actual product, served to specific users, teams, or companies through a targeted deployment. A real user logs into the real product, signs into a real account, and sees the prototype as part of the experience. Everyone else continues to see the production version. Lovable’s testing happens in a virtual browser—the agent clicks and fills forms to test the prototype—or via preview deploys to Lovable Cloud, Netlify, or Vercel. That works for design exploration and stakeholder review. It is not the actual product, and it is not in front of real users on real accounts in the real environment. (As of March 2026, Lovable’s Test and Live environments were deprecated for new projects.) ## Multiple frameworks under a single customer B2B SaaS companies often run more than one frontend framework — a marketing site on one stack, an admin tool on another, a customer-facing app on a third. Else covers all of those under a single customer account. Lovable is one React project at a time. A customer with a multi-framework reality manages Lovable against one slice of it—or manages Lovable in parallel with other prototyping tools for the frameworks Lovable does not support. ## When to pick Lovable A founder validating a new product idea, a PM building a 0→1 working demo for a stakeholder meeting, a designer exploring a concept without pulling engineering in—that is Lovable’s room. Lovable Cloud handles the backend, deploy is one tap, and the agent runs the build end-to-end. If the output of the work is a URL to send someone, Lovable is built for that. ## When to pick Else A product manager or designer with a product already in market—real codebase, real design system, real backend, real users—who wants the prototype to land inside that product, not next to it. The work has to look like an embedded part of the app the team already ships, span more than React, reach beyond GitHub, and end as a pull request engineering can review on the repo they already use. The reason to pick Else is the work where the prototype is not the destination—the merged PR is. ## FAQ ### Can Else run on an existing product, or is Else only for new apps? Yes, Else is built for existing products. Else writes against the customer’s real frontend repo from the first prompt, inheriting the components, CSS tokens, and design system already in production, and lands the work as a pull request engineering reviews. Lovable is at its sharpest as a 0→1 builder — Lovable Cloud bundles the backend, the database, and the deploy for new apps from a blank prompt — and on a product that already ships, Lovable’s design system lives in a separate `.lovable/rules/` project rather than inheriting from the existing codebase. ### Does Else work with Vue and Angular codebases? Yes. Else runs on any client-rendered SPA, including React, Vue, and Angular. The prototype is generated against the customer’s existing codebase, with no port and no rebuild between the prototype and the production framework. Lovable generates React + Vite + TypeScript only, so a Vue or Angular team has no path with Lovable today. ### How does Else handle our existing design system? Else builds the prototype out of the components, CSS tokens, and typography already in the customer’s codebase. The output looks like the product because it is built from the product. Lovable expects a separate design-system project where rules live in `.lovable/rules/`; Else reads what is already in production. ### Can a product manager or designer use Else without an engineer? Yes. Else is built around the assumption that the person at the keyboard is a product manager or a designer, not an engineer. The prompt design, repo permissions model, and deployment workflow all sit in front of a non-technical user. Engineering enters the workflow on the pull request, not before it. Lovable’s Agent Mode runs end-to-end without the user in the loop for each decision; Else is built for the PM or designer to be the one making each decision, with engineering entering on the PR. ### Does Else replace Lovable? No. Lovable is built for someone starting a new app from a blank prompt — a founder validating an idea, a PM building a 0→1 working demo for a stakeholder meeting, a designer exploring a concept. Else is built for someone who already has a product and wants the prototype to ship into that product across multiple frameworks, repo platforms, and the actual product itself. The two tools sit in different slots and can be used by different people on the same team. --- ## /resources/comparisons/else-vs-v0 Source: https://www.somethingelse.ai/resources/comparisons/else-vs-v0 Published: 2026-04-20

For the PM who needs the prototype to inherit the design system, not generate one

v0 opens the PR. The code is idiomatic React with shadcn and Tailwind on Next.js—exactly what v0 ships. The trouble is not the React. It is that “idiomatic React” is not the same as “your React.” Your team’s buttons, your team’s design tokens, your team’s component patterns do not live in v0’s output. Engineering opens the PR, agrees the code is fine, and starts the reconciliation pass anyway. Else writes against the components and conventions already in your codebase, so the PR uses your patterns from the first prompt—not v0’s defaults.

## TL;DR v0 generates React and Next.js components and, as of February 2026, opens pull requests into a connected GitHub repo. v0 is at its sharpest for engineers and dev-fluent product managers in a React, Next.js, and GitHub stack. Else runs on a customer’s real frontend codebase across React, Vue, and Angular, on GitHub, GitLab, or Bitbucket. Else inherits the existing design system, runs against the customer’s staging backend, and deploys prototypes inside the actual product for real user tests. Else is built for product managers and designers, with multi-framework support under a single customer. --- Both Else and v0 turn an AI prompt into a working prototype and end on a pull request. The difference is who is at the keyboard, what the prototype is built on, and how far the work can ship without a rebuild. Else is built for product managers and designers who need the prototype to look like an embedded part of their app and to land as a pull request engineering can review, test, and merge. ## The honest split v0 is at its sharpest as a React + Next.js + GitHub assistant. Else covers that same ground — and tends to be strongest there too — then keeps going: Vue, Angular, GitLab, Bitbucket, more than one framework under a single customer, and the design system already living in the customer’s codebase. The question is not which stack the team is on. It is whether one focused React tool is enough, or whether the prototype has to span everything the product is made of. ## Side by side | | v0 | Else | |---|---|---| | Who’s at the keyboard | Engineers, dev-fluent product managers | Product managers, designers | | Frontend frameworks | React + Next.js | React, Vue, Angular — any client-rendered SPA | | Repo platforms | GitHub | GitHub, GitLab, Bitbucket | | Design system handling | Generates with shadcn + Tailwind defaults | Inherits the design system already in the customer’s codebase | | Backend | Connects to existing Snowflake or AWS data; no auth, no business logic generated | Runs against the customer’s staging backend; supports full stack | | Live user testing | Vercel preview URLs | Targeted in-product deployments to real users in the actual product | | Output | Pull request to a connected GitHub repo | Pull request to a connected GitHub, GitLab, or Bitbucket repo | | Multi-framework per customer | One framework per project | Multiple frameworks under a single customer | ## Where v0 wins v0 is a sharp tool inside its native shape. For an engineer or a product manager with comfortable Git fluency working in a React + Next.js codebase already on Vercel, v0 turns a prompt into a working component fast. The shadcn + Tailwind defaults produce idiomatic modern React, and the GitHub branch-and-PR flow released in February 2026 means the output lands in the same repo the engineering team already uses, with a feature branch and a clean PR rather than an exported zip. If the work is a new component, a marketing page, or a UI proof inside an existing React app on GitHub, v0 is the shortest path to a working artifact. ## Inherits the design system already in your product Else builds the prototype out of what the product already uses. Components, CSS tokens, typography, spacing, the buttons engineering already styled, the modal pattern that already ships — Else writes against those rather than generating its own. The result is a prototype that looks like an embedded part of the product the customer ships, because it is built from the same code. There is no shadcn-to-our-design-system reconciliation step. There is no engineering review pass to make the prototype match the product visually before it can be tested in front of users. v0 produces idiomatic React with shadcn and Tailwind defaults. For teams that have not standardised on shadcn, every prototype carries a separate design-system reconciliation tax before it can ship inside the product. ## Built for product managers and designers Else is built around the assumption that the person at the keyboard is a product manager or a designer, not an engineer. The interface, the prompt design, the repo permissions model, and the deployment workflow all sit in front of a person who knows what should change about the product but is not writing the production code. v0 is now closer to a developer environment than it was a year ago. The February 2026 release added a VS Code-style editor, Git branch fluency, and direct repo connection. That is a sharp set of features for an engineer or a dev-fluent PM. It is more surface area to navigate for a designer or a PM whose role does not include managing branches and pull requests. The two tools are made for different people doing related but distinct work. ## Runs on the codebase, regardless of stack Else supports any client-rendered SPA: React, Vue, and Angular. A product manager at a Vue shop and a product manager at a Next.js shop use the same Else, on the same workflow, against the same kind of pull request output. v0 generates in React and Next.js. A team running on Vue or Angular cannot use v0 against their existing codebase — the framework simply is not supported. That is an entire category of B2B SaaS engineering teams (Vue and Angular shops are common in enterprise SaaS) for whom v0 is not an option for prototyping on the real product. ## Ships across GitHub, GitLab, and Bitbucket Else opens pull requests on GitHub, GitLab, and Bitbucket. A customer running engineering on GitLab or Bitbucket does not need to migrate, mirror, or stand up a parallel GitHub presence to use Else. v0 is GitHub-only. For teams whose primary repo platform is GitLab (common in self-hosted enterprise environments) or Bitbucket (common in Atlassian-aligned organisations), v0 has no path into the repo. The prototype-to-PR workflow only works if the prototype tool ships to the platform engineering already lives on. ## Runs prototypes inside the actual product Else deploys prototypes inside the customer’s actual product, served to specific users, teams, or companies through a targeted deployment. A real user logs into the real product, signs into a real account, and sees the prototype as part of the experience. Everyone else continues to see the production version. That makes user testing a test of the actual change in the actual environment, not a test of a sandboxed demo. v0 produces preview URLs hosted on Vercel. A preview is good for stakeholder review and design exploration. It is not the actual product, and it is not in front of real users on real accounts in the real environment. ## Multiple frameworks under a single customer Most B2B SaaS companies do not run on one frontend framework. A typical pattern: a marketing site in React or Next.js, an admin app in Vue, a customer-facing app in Angular, a partner portal in something else again. Else covers all of those under a single customer account. v0 is a per-project React tool. Each project lives in one framework, one repo, one stack. A customer with a multi-framework reality manages v0 against one slice of it. ## When to pick v0 A React shop on Next.js and Vercel, with engineering or a dev-fluent product manager at the keyboard, building a new component or landing page from a blank prompt — that is v0’s room. The output is a PR in the GitHub repo, the framework is the framework engineering already writes in, and the design system question is one engineering already owns separately. ## When to pick Else A product manager or designer who needs the prototype to look like the product, span more than React, and reach real users in the live app — that is Else’s room. Else covers React + GitHub teams as well, and that combination tends to be where Else is strongest. The reason to pick Else is the work that has to span beyond a single React project: a Vue admin tool, a GitLab repo, a design system that lives in the codebase, a live user test inside the product the customer already ships. ## FAQ ### Does Else work with Vue and Angular codebases? Yes. Else runs on any client-rendered SPA, including React, Vue, and Angular. The prototype is generated against the customer’s existing codebase, with no port and no rebuild between the prototype and the production framework. ### How does Else handle our existing design system? Else builds the prototype out of the components, CSS tokens, and typography already in the customer’s codebase. The output looks like the product because it is built from the product. There is no separate reconciliation step between the prototype and the pull request engineering reviews. ### Does Else open pull requests on GitLab and Bitbucket? Yes. Else supports GitHub, GitLab, and Bitbucket. A team running engineering on GitLab or Bitbucket does not need to migrate or mirror to use Else. ### Can a product manager or designer use Else without an engineer? Yes. Else is built around the assumption that the person at the keyboard is a product manager or a designer, not an engineer. The prompt design, repo permissions model, and deployment workflow all sit in front of a non-technical user. Engineering enters the workflow on the pull request, not before it. ### Does Else replace v0? No. v0 is a focused tool for generating React components from a prompt, especially inside a Next.js + GitHub workflow. Else is a prototyping environment for product managers and designers working on the existing product, across multiple frameworks, repo platforms, and the actual product itself. The two tools sit in different slots and can be used by different people on the same team. --- ## /resources/use-cases/ship-copy-and-color-changes Source: https://www.somethingelse.ai/resources/use-cases/ship-copy-and-color-changes Published: 2026-05-11 *For the PM who knows the button label is wrong but calculates the cost of asking engineering to fix it. What happens when you don’t have to.* **The button label is wrong. The empty-state copy hits flat. The palette is off by a shade. Each fix is twenty minutes of work, and each one runs through the same calculation: is this worth asking engineering for? The list grows, the calculation answers the same way every time, and at some point the PM stops asking.** ## TL;DR Most PMs stop asking engineering to fix small things because the cost of asking is bigger than the change itself. A copy update sits in planning. A button color enters the queue behind a feature nobody disputes matters more. The fix is two minutes of work and four weeks of waiting. Else lets the PM build the change inside the actual product, test it with internal users or a small customer cohort, and open a pull request engineering reviews like any other. The artifact is durable. The change doesn’t disappear because no one owned it through the handoff. --- Else lets PMs and designers prototype and test inside their actual product, then hand engineering a PR they merge, not rebuild. Copy updates, color changes, microcopy fixes – the ones that never justified the engineering ticket – open as PRs on the team’s repo and run through the same review every other PR runs through. ## The small-change problem Alexander, a PM at VEO, describing the moment he stopped putting copy updates in the engineering queue: > “Why am I putting so much effort and work onto other people to make, let’s say, a copy update or a color change?” He moved from a question to a statement. *Can I justify asking engineering for this?* became *I will deploy this*. The shift is small but structural. Every copy update, every color tweak, every microcopy clean-up that used to sit on the wrong side of that question now ships. ## What sits in the queue The Head of Growth at an online marketplace based in the UK has been documenting the backlog for a year. Two-day API fixes that have been sitting in engineering planning for six weeks. Copy fixes batched with features that took the team a sprint, all pushed out together so the PM’s directional call – soften this error, fix this typo – gets diluted into the larger change. Small changes accumulate into the experience customers have of the product. Because each one looks trivial alone, they move to the end of the line. A PM collects them, the list grows, and the calculation that decides whether to ask gets answered the same way every time. ## How Else does it Three specific shapes. **1. Copy and microcopy.** Button labels. Error messages. Empty-state text. Confirmation dialogs. Onboarding strings. Anything where the change is the text itself. **2. Visual tweaks.** Color shifts. Button sizes. Padding adjustments. Link styles. Spacing changes that don’t require backend work or component rework. **3. Light refinements.** The ones that stack up over months: a better label on the help text, a softer error tone, a tooltip that clarifies the flow, a button label that matches the user’s mental model instead of the engineer’s. Tools like [Lovable](/resources/comparisons/else-vs-lovable) or Bolt sit next to the codebase. The change you build there is a sketch engineering rebuilds inside your actual product. Else lands inside the codebase from the start. The PM builds the change in the actual product, tests it with a link to internal users or a small customer cohort, and – when ready – opens the PR directly against the repo. Engineering reviews a pull request that looks like any other PR. Merge or don’t. The time from noticing a label is wrong to seeing it in production stops being measured in sprints. This is what [vibe coding for product managers](/resources/field-notes/vibe-coding-for-product-managers) looks like when it stays inside your actual product. ## Proof The Head of Growth opened his first Else PR – a new front-end form field for users to fill in – an hour after a working session with Else. He expected it on the live site the next day. A Director of Product Management at a US B2B SaaS has run the same play. The tactical fixes that used to sit in the *should-we-even-ask* category have shipped as PRs through Else, reviewed and merged like any other contribution on the team. ## FAQ ### Isn’t this just for copy and color? That is where teams *start*. Copy and color have a low cost of failure – if the change doesn’t land well, the next version is hours away. Teams that ship small changes cleanly move into larger work next: button restructuring, flow refinements, feature-flag-gated experiments. The progression works because each step is a PR engineering reviews, not a sandbox artifact that might evaporate. ### What if the copy is wrong after it ships? Same as any PR. If the copy isn’t landing, the PM or someone on the team writes a follow-up PR. No PRD, no ticket, no queue – just the next version. ### Doesn’t this break our design process? It shifts it. Design still owns the direction and the system. What changes is when they’re consulted. Some teams do a design review on the prototype before the PR opens. Others have the designer and PM working together inside Else on the change. The design system doesn’t go away – it’s inherited directly into the prototype because the prototype runs on the repo. ### How does this work with our brand guidelines? Same way it works with engineering – the guidelines are on the repo, you inherit them, you work inside the constraints. If the change violates your brand rules, that’s what the design review is for. If it doesn’t, it ships. ### What if our engineering culture won’t merge a PR from a PM? That is a conversation worth having before the first PR opens. Most teams that see the PR – it looks like code, it passes the tests, it changes exactly what the PM said – accept it without argument. Some cultures reject the pattern outright. If that’s your team, you will know it after the first attempt. The value of the PR is that it makes the conversation concrete instead of letting it happen in async comments or closed tickets. ### What scope have design partners actually shipped this way? The scope is not limited to copy-and-color fixes. Full flows are in scope. The first PRs design partners ship are typically the ones in the *too small to justify the ticket* category – the copy fix, the button-label change, the spacing adjustment that should have shipped months ago. That early win builds the muscle. Larger work comes next, once the team trusts the artifact – see [ship a production PR without writing code](/resources/use-cases/ship-production-pr-without-coding) for the validated-prototype-to-PR path. --- ## /resources/use-cases/prototype-with-real-data Source: https://www.somethingelse.ai/resources/use-cases/prototype-with-real-data Published: 2026-05-08 *For the PM who has shipped a prototype that worked perfectly until the customer’s real account hit the page. What changes when the prototype runs on the actual backend.* **The customer’s real account is the thing the prototype never saw. Seven-year billing history. Tenant-specific permissions. A feature flag locked on from a prior experiment. The flow that worked on the PM’s laptop breaks on day one of production – and engineering rebuilds the feature to fix it.** ## TL;DR Most prototyping tools mock the data. The dropdown that listed three products renders three hundred when a real customer hits it. The seven-year billing history breaks the table. Engineering ships the feature, then ships the rebuild that handles the real conditions. Else runs the prototype against your actual backend – the real API, real accounts, real permissions, real feature flags. The failure surfaces in your editor, when you still have time to fix it. --- Else lets PMs and designers prototype and test inside their actual product, then hand engineering a PR they merge, not rebuild. --- ## Why mocked-data prototypes break A PM builds a visual flow in Lovable. The customer watches a demo on the PM’s laptop and approves it. Engineering ships the feature three weeks later. On day one of production, the real data arrives. The customer’s account has a seven-year billing history. The dropdown that listed three products renders three hundred. Each one a small problem the prototype never had to confront, because the prototype was a drawing under invented conditions. --- ## The two categories Drew Muller ships at Ferry Drew Muller is the Director of Product Management at Ferry International, a real estate coaching, training, and education company. The features he ships split almost evenly into two categories. Visual flows – navigating courses, exploring learning paths – “are really easy to spin up with Figma Make or another vibe-coding tool.” Business tools are different: “Those do require data to be functional. They require user data.” The first category runs cleanly in sandboxed prototyping tools because the design is the deliverable. The second depends on the data behaving the way real customer data behaves. --- ## How Else runs the prototype on real data Else runs the prototype against your actual backend – the real API, accounts, permissions, feature flags, and data. When the prototype calls the billing history, it calls the actual endpoint. The data it loads is the data your users see. For new fields the prototype depends on – something the backend does not return yet – Else adds a prototype-only data layer. Your backend stays untouched. When the scope requires actual backend work, Else exports a backend spec and a handoff prompt alongside the frontend PR. The engineer building the new endpoint receives the spec with the ticket. --- ## The edge cases that break sandbox prototypes Sandbox prototypes hide failures until production: - Enterprise accounts with multi-year billing histories. Tables built for fifty rows break at fifty-three. - Tenants with custom permissions. Authorization fails because the check assumes a standard role. - Customers with feature flags locked on from old experiments. New features conflict with old state. - Timezone mismatches. The prototype tested in UTC; the customer is in Los Angeles. - Currency formatting. Mocked USD; the customer operates in EUR with different decimal rules. - Volume. The query returns three hundred items; the prototype tested with ten. - Account state. The customer has an inactive subscription, a past-due invoice, a refund pending. Lovable, Bolt, v0, and Figma Make were all built to handle a blank canvas. A blank canvas has none of these conditions. See [Else vs Lovable](/resources/comparisons/else-vs-lovable) for the head-to-head. --- ## Breaking before production Mocked-data prototypes hide the failure until production. The real conditions – real volume, real edge cases, real state transitions – arrive on day one. By then engineering has rebuilt the feature. When the prototype runs on real data, the failure surfaces in your editor, when you still have time to fix it. For how this changes the handoff to engineering, see [ship a production PR without coding](/resources/use-cases/ship-production-pr-without-coding). For the broader argument on prototyping inside an existing codebase, see [prototype on a real codebase](/resources/use-cases/prototype-on-real-codebase). --- ## FAQ ### What about PII? Do we see customer data we shouldn’t touch? The prototype runs in a sandbox – a version of your product visible only to the PM and the users you target. PII is visible to the user it belongs to (because that is who the prototype is for), but it is not exported from your environment. ### Does the prototype see production data we don’t want PMs touching? You control the data layer. The prototype reads whatever your backend exposes to the users it is targeting. If your backend does not return a sensitive field to that user in the real product, the prototype does not see it. Hide a field at the API level the same way you hide it from any user. ### How do you handle staging versus production? Else is agnostic to your backend environment. Point it at staging, it runs on staging. Point it at production, it runs on production. The typical flow is to prototype in staging first, test against staging data, then run a real experiment against production data with a feature flag limiting visibility to a test cohort. ### What if our backend has no OpenAPI spec? Else still works. The extension reads whatever it can from the frontend repo’s existing API calls and from runtime traffic. If your frontend is already calling an endpoint, Else can see the shape of the response. An OpenAPI spec makes the inference cleaner, but it is not required. ### Can we test with synthetic users instead of real ones? Yes. You can create synthetic accounts in your database (the way you do for QA), and the prototype will load them. The data is real; the identity is synthetic. This is common for fintech and healthcare teams who need to validate against real data shapes without using live customer accounts. ### What about feature flags? The prototype loads the real feature flag state for the user it is targeting. If a user has a flag locked on from a previous experiment, the prototype sees that. If a user has a flag locked off, the prototype respects it. The PM no longer has to manually describe the flag state to a designer who approximates it in a mockup. --- ## /resources/use-cases/pm-ship-feature-without-engineering Source: https://www.somethingelse.ai/resources/use-cases/pm-ship-feature-without-engineering Published: 2026-04-27 *For the PM who spends more time calculating whether to ask engineering than describing what she’d ask them for. What changes when the artifact is the PR.* **The PM has the bet. The customer is on the call. Engineering is committed for the quarter. The math runs the same way every time: the cost of interrupting a committed sprint is bigger than the size of the ask, and the ticket dies in the PM’s draft folder before anyone else sees it.** ## TL;DR The PM doesn’t have to ask engineering to drop what they’re doing. The ask changes shape. The PM builds the prototype against the real frontend, validates with real users, and hands engineering a PR to review – not a ticket to staff for a sprint. Engineering’s time goes into code review, tests, production posture, architecture calls. The PM’s time goes into deciding the bet, validating with users, committing to a direction. Both keep the part of the job only they can do. --- ## The calculation A PM at DeepHow, describing the math she runs before filing any ticket: > We need to figure out if the juice is worth the squeeze before we start ringing everyone’s bells on our engineering team. Hey guys. Drop what you’re doing. We’re focused on this.” > – Product Leadership, DeepHow The protocol runs four questions. The old answer pulls the ticket back before it leaves the PM’s draft folder. The new answer – where the artifact is a PR, not a PRD – changes all four. --- ## Question 1. Is this worth asking engineering to drop what they’re doing? **Old answer.** If the engineering team is tied up for months, the threshold to ring their bells goes up. Many PM ideas die at this question. The cost of interrupting a committed quarter is higher than most asks can justify, and the PM self-censors before anyone else gets to say no. **New answer.** The ask changes shape. The PM is no longer asking engineering to drop what they’re doing and build. She is handing them a PR to review when the prototype is ready. Review time is smaller than build time, and it falls on a smaller surface. --- ## Question 2. Can I describe this well enough for someone else to build it? **Old answer.** This is the question that eats a PM’s week. A prototype in [Lovable](/resources/comparisons/else-vs-lovable) or Figma Make settles the behavior question – the customer clicked, the flow worked – but the PRD still has to translate that behavior into something an engineer can pick up. Imaginary prototype becomes a PRD. PRD becomes a ticket. Engineering reads the PRD, looks at the prototype, and starts from scratch on the real codebase. **New answer.** The prototype is the description, and the PR is the prototype. The PM builds against the real frontend, targets real users, sees the flow working on the real product – and the build is what gets reviewed. Engineering reads code, not descriptions of code. --- ## Question 3. Will what they build match what I showed the customer? **Old answer.** The cost of the translation layer every PM running this play pays – in explanations back to the customer, in the second round of tickets when the shipped version behaves differently from the prototype they signed off on, in the sprint the PM thought was over. This is the [vibe-coded work that disappears](/resources/field-notes/pattern-vibe-coded-work-disappears) at handoff. **New answer.** There is no translation. The PR contains the code the prototype ran on – the components from the design system, the CSS from the repo, the conventions from the team. --- ## Question 4. Will it survive the next sprint reshuffle? **Old answer.** Engineers tied up for months, roadmap defended for the quarter, and every incoming idea landing on a queue that is already full. A PRD and a Lovable link don’t survive that. The validated prototype goes into a Figma file. The customer conversation that motivated the ticket becomes a paragraph in a doc nobody reads next quarter. **New answer.** The work exists as a PR against the repo from the moment the prototype is done. It ships or it doesn’t, but the build doesn’t evaporate into PRD-limbo while the team pivots. The artifact is durable in a way a ticket description is not. --- ## What changes in the PM’s relationship to engineering The old relationship: the PM asks, engineering decides, engineering builds, the PM explains the gap to the customer. The new relationship: the PM builds, engineering reviews, engineering merges, the PM explains the shipped behavior to the customer. Engineering’s time goes into the part only they can do – code review, tests, production posture, architecture calls. The PM’s time goes into the part only she can do – deciding what to build, validating it with users, committing to a design direction. This is what [vibe coding for product managers](/resources/field-notes/vibe-coding-for-product-managers) looks like in practice. The PM owns the bet. Engineering owns the merge. --- ## What you built is what ships

What you tested is what ships. No “they rebuilt it and lost the design.” The prototype matches the code. Your intent survives the handoff.

--- ## FAQ ### Isn’t this engineering’s job? Else is not an IDE for PMs. It is the path between a validated bet and a PR engineering can review. Engineering still owns the merge, the tests, and the production posture. The PM owns the bet and the build. What moves is the shape of the handoff, not the boundary between the roles. ### Who owns QA? Engineering does. The PR Else opens runs through the same CI pipeline, the same tests, and the same merge gate as any other PR. PMs typically do their own behavioral QA in the prototype – the flow they showed the customer is the flow in the PR – but production-grade QA sits on the engineering side. ### What about security or compliance review? It happens on the PR, the same way it happens for any PR on the repo. There is no second review surface. If the team has a security checklist that runs on every PR, it runs on this one. ### Does this break our merge or deployment process? The Else PR is a frontend PR on the repo. Whatever tooling already runs on merges – required reviewers, required checks, required deploys – runs on this one. The process is not something Else replaces. ### We have a design team. Where do they sit in this? Unchanged in principle – design owns the direction, the system, and the review of what the PM builds against. Some teams run a design-review step on the prototype before the PR opens; others have the designer working alongside the PM inside Else. It depends on how the team already operates. ### Our engineers will rewrite whatever we hand them anyway. That is the pattern most PMs have lived – the 10-50%+ rework. The reason the rework exists is that the prototype lives somewhere the codebase doesn’t. Else writes against the real frontend, inherits the components and CSS already shipped, and opens the PR directly on the repo. ### What if our engineering culture rejects a PR from a non-engineer? That is a conversation to have with engineering before the first PR opens, not a reason to skip the attempt. Most objections collapse when the PR shows up looking like a PR from the team. Some cultures will not accept this workflow at all – that is also useful information. The point of the PR-as-artifact is to make the conversation concrete, not to win it by default. ### How does this land on the roadmap conversation with my VP? The conversation changes from ‘please staff this for a sprint’ to ‘here is a PR against the repo; here is what it changes; here is what we saw when users touched it.’ That is a different ask. Whether it lands depends on the VP – but the artifact is concrete, testable, and already in the shape engineering reviews. --- ## /resources/use-cases/prototype-on-real-codebase Source: https://www.somethingelse.ai/resources/use-cases/prototype-on-real-codebase Published: 2026-04-21 *For the PM whose prototype keeps failing the ‘but it’s not our product’ test. What changes when the code runs on the frontend your team shipped.* **The prototype looked right on the PM’s laptop. The customer signed off. Engineering opened the file, looked at a design system rebuilt from screenshots, and started the whole thing over from the real components. The prototype was a sketch. The product is the rebuild.** ## TL;DR Sandbox prototyping tools generate code against a copy of your design system. The result looks close but isn’t your product – which is why every customer demo from one of these tools risks the “kinda right” verdict and every PR engineering writes is a rebuild from scratch. Else runs on the four things that make a prototype actually your product: the design system in your repo, the staging backend, your auth and feature flags, and the PR itself. Same components, same data, same users, same merge gate. --- ## ‘It has no knowledge of our code base’ A PM at Airbyte, describing what happens the moment he opens a general-purpose prototyping tool on an existing product: > Whenever I initially ask, it has no knowledge of our code base… It’s still that handoff where I describe what I want, now, Engineering has to go start from scratch.” > – Matteo Palarchio, Airbyte The prototype was supposed to shorten engineering’s work. In a sandbox tool, it adds a step. For why this matters across every kind of AI prototyping tool, see [the AI-prototyping playbook for product managers](/resources/field-notes/ai-prototyping-for-product-managers). ‘Your product’ is not a visual thing. It is four specific technical things the prototype either runs on or doesn’t. Else runs on all four. --- ## 1. The design system A PM at HP named the specific failure: > The limitation with Lovable is that you have to recreate your design system every time.” > – Product Ops, HP Every sandbox tool – [Lovable](/resources/comparisons/else-vs-lovable), Bolt, v0, Figma Make – writes code against a copy of something that looks like your design system. Tokens get approximated. Components get re-implemented from screenshots. States are mostly right. A PM at Monotype relayed the customer reaction to a demo that came out of this loop: > Kinda looks close. It’s kinda right, but it’s not my product.” > – Diego Schmunis, Monotype The ‘kinda right’ state is the predictor of design-system rejection in review – the [start-over pattern](/resources/field-notes/pattern-design-said-start-over) is how that scene plays out in detail. Else installs as a GitHub app on the frontend repo and writes against the components and CSS already in production – the same `