In this episode of Semaphore Uncut, we sat down with Keren Fanan (CEO & Co-founder) and Hadar Geva (CTO & Co-founder) of MyOp to talk about one of the hardest problems in frontend engineering: how to keep shipping UI as frameworks, tools, and expectations change—without constantly rewriting your application.
Drawing on their experience building and scaling products at companies like Get, Moon Active, Wix, and Jive Software, Keren and Hadar explain why frontend systems tend to calcify over time, and how MyOp rethinks UI as a runtime system rather than a static part of the codebase.
From Scaled Products to a Shared Frontend Problem
Both founders come to MyOp with extensive experience operating large, production-grade products.
Keren Fanan spent years leading product, revenue, and monetization teams at Get and Moon Active, where UI changes were tightly coupled to growth and experimentation. Hadar Geva led frontend architecture and developer experience at Wix, overseeing technical direction for hundreds of frontend engineers across multiple product groups.
Despite working in different roles, they encountered the same recurring issue: frontend systems rarely evolve cleanly. Framework upgrades introduce breaking changes, legacy code persists far longer than intended, and teams end up running multiple frameworks side by side with no safe way to experiment or iterate.
What MyOp Is Building
MyOp is a frontend development platform that allows teams to plug external, independently deployed UI components directly into a live production application.
Instead of baking every UI change into the main codebase, MyOp introduces a runtime layer between application logic and UI. Components are loaded dynamically, managed remotely, and can be swapped or rolled back without redeploying the host application.
This approach allows teams to ship UI updates without redeploying the core application, run experiments directly in production, mix frameworks like Angular, React, Vue, and Web Components, modernize legacy frontends incrementally, and integrate AI- or low-code–generated UI without committing to long-term architectural decisions.
Components as Runtime Contracts
A central idea behind MyOp is redefining what a component represents.
In MyOp, a component is a contract rather than a specific implementation. The contract defines how a component renders into the DOM, how it receives props and refs, how lifecycle events are handled, and how cleanup occurs.
That same contract can then have multiple implementations—referred to as variants or skins—built with different frameworks or UI approaches. This abstraction makes framework integration lightweight, often requiring only a small adapter layer.
Integrating MyOp into an Existing Application
Adopting MyOp does not require a rewrite.
Teams add a small Host SDK to their existing application, either via import or script tag, and call a function to load a component into a specific DOM element. From that point on, MyOp manages rendering, lifecycle, and updates for that subtree, while the rest of the application remains unchanged.
Remote components can live in separate repositories, be deployed independently, and be tested independently. The host application becomes stable, while UI development becomes more flexible.
Runtime Rollouts, Segmentation, and Experiments
Because components are loaded at runtime, MyOp naturally supports segmentation and controlled rollouts.
Instead of shipping multiple versions of a component behind feature flags in the same codebase, MyOp evaluates which variant to load at runtime based on segments. Segments are defined as simple async boolean functions inside the host application and can reflect any internal logic—such as user type, environment, or account status.
In practice, this makes it possible to release UI changes only to internal users or QA, run production previews without spinning up additional environments, roll changes out gradually to a subset of users, and instantly revert if something goes wrong—all without redeploying the host application.
All of this happens inside real production traffic, without duplicating infrastructure or branching code paths.
How This Differs from Micro-Frontends
While MyOp shares some similarities with micro-frontend architectures, the founders see it as a broader approach.
Traditional micro-frontends focus on splitting applications at build time. MyOp focuses on runtime orchestration, framework-agnostic components, and centralized UI control. This orchestration layer is often the missing piece in micro-frontend implementations, where teams stop once independent deployment works but struggle with long-term management.
MyOp adds that missing control plane for UI.
MyOp in 2025 and the Role of AI
MyOp has been live for just over a year. After securing pre-seed funding, the team built and released the first version with early customers and is now opening the platform more broadly.
The MyOp SDK is open source, and the platform offers a freemium tier for developers who want to experiment.
AI is a major driver behind MyOp’s direction. Many AI-generated UI components default to specific frameworks, creating friction for teams with existing codebases. MyOp acts as a connector, allowing teams to test AI-generated or externally built UI safely in production without committing to a single tool or framework.
Getting Started
Developers interested in exploring MyOp can visit myop.dev, where they’ll find documentation, code examples, and access to the MyOp dashboard.
The team encourages hands-on experimentation as the best way to understand how runtime UI composition changes the way frontend systems are built and operated.
Resources
- Website: https://www.myop.dev
- LinkedIn:
