How the Frontfriend eject service converts your application into a self-contained codebase

Eject and Portability

Frontfriend eject is a managed handover service that converts a selected version of your application into a self-contained codebase.

After the handover, your team can install, build, deploy, and maintain that version without:

a Frontfriend account;
access to Frontfriend cloud services;
Frontfriend credentials in the build pipeline;
Frontfriend services at runtime; or
@frontfriend/tailwind in the application's dependency graph.

The result is a fixed snapshot of the application at the time of handover. It is not a standalone copy of the Frontfriend platform.

This page describes the eject service. The repositories, design files, features, dates, acceptance criteria, support, and commercial terms for a specific eject are defined in its written handover agreement.

What you receive

The exact deliverables depend on the agreed scope. A typical eject includes:

the application source at an identified Git commit or tag;
project-local component, styling, and asset source required by that application version;
an independent copy of the included Figma UI Kit, when design files are part of the scope; and
support contacts and the dates of the review-and-support window.

The delivered application continues to use its normal framework and development workflow. Your team can review and change its React or Vue components, Tailwind utilities, CSS, icons, and other application source directly.

Target state

An eject is ready for acceptance when the selected application version meets the criteria defined in the handover agreement. These normally include:

Area	Expected result
Installation	Dependencies install from the project's standard package registry without Frontfriend credentials.
Build	The application builds without Frontfriend cloud access or previously generated Frontfriend data.
Runtime	The deployed application makes no requests to Frontfriend services.
Components	The component source required by the snapshot remains in the application repository.
Styling	The agreed visual baseline is represented with standard Tailwind utilities and project-local CSS.
Design files	Included Figma files can be used without an operational Frontfriend dependency.
Maintenance	The receiving team can change the delivered source through its normal development workflow.

How the handover works

1. Define the scope

Frontfriend and the receiving team agree on:

the repositories, branches, and application version to include;
the Figma files and pages to include;
supported frameworks and environments;
important routes, responsive layouts, and component states;
any runtime brand or theme behavior that must remain available;
the acceptance criteria and reviewers;
the delivery date; and
the support and commercial terms.

These decisions are recorded before conversion begins.

2. Freeze the application version

Both teams identify the exact Git revision and design-file versions that form the handover baseline. Changes made after that point are not automatically included.

3. Prepare the independent snapshot

Frontfriend removes the selected application's operational dependency on Frontfriend. The components, styles, icons, and utilities needed to preserve the agreed application baseline are prepared as project-local source.

When Figma files are included, Frontfriend prepares the agreed design content so it can be used without access to the Frontfriend workspace. Hosted synchronization, managed versioning, and other platform functions are not embedded in the delivered files.

4. Validate the result

Frontfriend verifies the snapshot from a clean environment without Frontfriend credentials or previously generated Frontfriend data. The final application is compared with the agreed baseline.

5. Deliver and accept the handover

Frontfriend delivers the agreed snapshot and deliverables on the communicated delivery date. Delivery starts the review-and-support window defined in the handover agreement.

During this window, the receiving team performs its own clean installation and build, reviews the agreed routes and design files, and reports any reproducible differences from the agreed baseline. Frontfriend resolves reported differences as part of the handover. Requests that go beyond the agreed baseline are separate engineering activities.

When the window closes, the handover is accepted and the receiving team owns the engineering workflow for the delivered snapshot.

Responsibilities

Frontfriend is responsible for

preparing the snapshot described in the handover agreement;
removing Frontfriend build and runtime dependencies from that snapshot;
providing the agreed source and design files; and
supporting the handover during the review-and-support window.

The receiving team is responsible for

confirming the repositories, Figma files, environments, and application version in scope;
identifying the routes, states, and behavior that are important for acceptance;
providing the access and technical information required for the handover;
reviewing the delivered source and third-party dependencies;
performing a clean installation and build during the review-and-support window;
reporting reproducible differences from the agreed baseline within the review-and-support window; and
maintaining, securing, upgrading, and deploying the application after acceptance.

What stops after eject

Unless a separate active service says otherwise, the snapshot no longer receives:

cloud token synchronization;
managed component and style updates;
hosted previews and release channels;
automatically generated component API documentation (Storybook) for the design system;
automatic propagation of design-system changes;
Frontfriend context for AI development tools; or
future Frontfriend component releases.

Future changes to components, colors, typography, spacing, icons, dependencies, and application behavior are made directly in the receiving team's repositories and design files.

If the application needs a semantic design-token layer after eject, the receiving team's designers and engineers should define and maintain that vocabulary as part of their own design system.

What is not included

An eject does not include:

a copy of the Frontfriend platform, CLI, hosted services, or synchronization technology;
Frontfriend's internal source libraries, generators, or operational tooling;
future managed updates;
features or application versions outside the written scope; or
new feature development, rebranding, dependency upgrades, or design-system evolution unless explicitly included.

Ownership and third-party software

Ownership of the delivered snapshot follows the Frontfriend Terms and Conditions. You own the application code, components, screens, and project files in your repositories, including customer application source delivered through the eject.

The Frontfriend platform, hosted services, synchronization systems, release-management tools, and other proprietary technology are not part of the snapshot.

Delivered source may include or depend on open-source libraries and third-party packages. Those libraries and packages remain subject to their own licenses.

Support after handover

Review and support share a single window: it starts on the delivery date, and its duration is defined in the handover agreement.

During the window, support focuses on:

assistance with the first clean installation, build, and deployment; and
reproducible differences from the agreed baseline introduced by the eject.

When the window closes, the handover is accepted. New features, rebranding, design-system changes, dependency upgrades, and issues introduced by later project changes are separate engineering activities.

Requesting an eject

Contact your Frontfriend representative to define the scope, timing, acceptance criteria, and commercial terms. Frontfriend will prepare a written handover agreement before work begins.

Eject and Portability

On this page