Fork

Fork is a developer platform that lets the people using your software ask for a feature and actually get it, built on top of your real app rather than dropped into a wish list. A customer opens Fork inside your product, describes the change they want in plain language, and a coding agent builds it from your codebase. The result is a private branch that belongs to that user, so your app can bend to fit each customer without your team writing every one-off request by hand.

The idea behind it is that highly personalized software is where things are heading, and most teams can't staff the backlog that idea creates. Enterprise buyers want a button moved, an export added, a report reshaped, and today those requests either wait months or never ship. Fork turns that queue into something users can drive themselves, inside limits you set, so the long tail of small customizations stops being a cost center and starts being a feature of the product.

In practice a user with a feature request opens Fork, types something like add a quick-action button that exports all items, or highlight overlapping meetings, and the agent builds it against your codebase. An isolated git worktree is created for the work, the change runs in a sandbox, and the person ends up with a branch that personalizes the app just for them. Every prompt and every resulting fork is recorded under the owning container, so nothing happens off the books and you can always see who asked for what.

It works as a lightweight SDK that drops into your existing stack with no rewrites and no migrations. You add the SDK with one line, then mark the parts of your app you're willing to let people change as Forkable surfaces, each tied to a module boundary. The SDK also ships a complete chat surface, so the simplest integration is a single component that gives users a place to describe what they want and watch it get built. From there you can compose the underlying hooks yourself if you want a custom interface.

The domain model is small and consistent. An app is your host application, registered under a tenant and connected to one GitHub or GitLab repo. A container is a named, shareable branch of work backed by a git worktree that holds a chain of forks, and a fork is a single customization that belongs to one container and targets one module boundary. Under the hood a customization is delivered as a separate module bundle that runs in the same JavaScript context as your host app, and the SDK shares your existing React instance so nothing gets double-bundled or reaches into server-only code.

Structure and control sit at the center of the design. You define the constraints, permissions, and scope, so people can only touch the surfaces you've opened and nothing sensitive. An admin view lists every fork across the app, lets you filter by status, and drills into each container's chain. Access runs through per-user logins, each teammate's Fork identity links to their end-user identity in your app, and branches execute in sandboxed environments with data encrypted in transit and at rest. Fork also states it doesn't use your personalization inputs or branch state to train models and doesn't sell personal data.

Setup is meant to take minutes rather than months. You install the Fork GitHub app on a repo, finish the installation and choose the repository to connect, and Fork hands you an app ID, a publishable key, and a secret key to drop into the SDK. The publishable key is safe in the browser while the secret key stays on your server, and Fork keeps a canonical clone of your repo that it rebases before every run so the agent always builds against current code. From there, marking a surface Forkable is one more line.

Fork fits SaaS teams whose customers keep asking for bespoke features the roadmap can't absorb, especially products serving a handful of high-value accounts that each want the software shaped their way. Because it runs alongside your codebase instead of replacing anything, there's no architectural change and no vendor lock-in. It's a weaker fit if you're not on a standard git and JavaScript stack, since GitHub is supported today and GitLab connect is noted as coming soon.

Access is free to start with no credit card, framed as enough to ship custom features for your first handful of customers. Larger teams move to volume pricing with dedicated support and custom integrations for shipping at scale. The closer you already are to a modern React app in a connected repo, the faster the wiring goes, and the more of the roadmap you can hand back to the people actually using the product.