Hadar Geva

Client-side frontend code should not be the exclusive domain of frontend developers because modern tooling, AI, and other platforms make it possible for designers, product, and marketing teams to safely own, iterate, and ship UI without touching backend logic or risking core stability. Frontend engineers can then specialize in the architecture, contracts, and business logic that matter most, while non-dev stakeholders directly shape the experience layer where they have the deepest expertise.

Shipping UI changes across multiple environments sounds straightforward until a product and team start to scale. Suddenly there is production, staging, QA, demo, internal dogfood, sometimes region-specific environments, and each needs slightly different UI states at different times.

A new onboarding flow might belong in staging, a stable checkout in production, and an experimental header only in a demo or beta environment. Without a solid approach, teams end up with a tangle of environment-specific hacks, confusing configurations, and a constant fear of shipping the wrong UI to the wrong users.

Q4 2025. A designer asked a question that crystallized everything we'd been building toward: "Why do I need a developer to deploy the component I just generated with AI?"

She had used Claude to generate a promotional banner. The HTML, CSS, and JavaScript were ready. It looked exactly right. But getting it from her screen to production still required a developer to review it, integrate it, test it, and deploy it. "The AI wrote the code in five minutes," she said. "Why does deployment take five days?"

That question launched Myop Version 2.0.

TL;DR: We wanted a new look and feel for our Component Dashboard. So, instead of tons of PRs getting rejected, we let our UI Design and Product team build it for us with AI in an isolated Myop component. As devs, we made sure the props and architecture for data flow was pristine and just handed them the reins to build the component itself.

In the first part of this series, we discussed the gatekeeping dilemma for devs and how non-devs have access to code already. And we went through the better approach devs should take to democratize code but with good governance. So how do we actually implement that and what does it mean for you the developer?

Introduction: The Gatekeeper's Dilemma​

In my previous blog post on this topic, I wrote in short about this. In short, constant UI change requests disrupt front-end developers' focus and slow overall progress.

In the fast-paced world of business, agility and adaptability are no longer optional, they’re essential. For years, the role of engineering leadership — whether as a CTO, VP of Engineering, or R&D head — has often been seen as a gatekeeper, tasked with managing scope, meeting deadlines, and maintaining stability by pushing back on requests. But with the right tools, engineering leaders can shift from gatekeepers to enablers, driving business growth and innovation.

Micro frontends aim to break up a large monolithic frontend application into smaller, independently deployable pieces. This allows teams to develop, test, and deploy individual parts of the UI separately, but it comes with its own set of challenges, particularly around integration and consistency.

In today's fast-paced digital world, user interfaces (UIs) are no longer static entities—they need to be dynamic, flexible, and adaptable to ever-changing requirements. Whether it’s a bug fix, feature update, or a complete redesign, developers face the challenge of making changes to UIs without breaking core functionality. What if there was a way to build UIs that could change in real-time, evolve post-launch, and optimize seamlessly, without ever reopening the core code?

As a co-founder and CTO at Myop.dev, I’m excited to share the journey we’ve been on to completely transform how UIs are built, managed, and evolved. At Myop, we’re focused on creating a platform that allows developers to dynamically update and manage their user interfaces in ways that weren’t possible before—without having to modify the core code.