Introducing Myop V2: Welcome to the AI and MCP Future

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.

The V2 Vision

Version 1 of Myop assumed developers were always in the loop. They created components, configured them, tested them, and deployed them. Non-developers could make limited changes like swapping content and adjusting settings, but the fundamental workflow centered on engineering. V2 would flip this assumption.

What if the primary users were designers, product managers, and growth teams? What if developers set up the guardrails once and then stepped back? What if AI-generated components were first-class citizens, deployable without code review?

This wasn't about removing developers altogether. It was about removing them from the critical path of releases and re-releases. Developers would build infrastructure: integration points, security boundaries, performance budgets. Everyone else would build experiences.

The Component Builder Revolution

Our old component creation flow assumed you knew what you were doing. Start with a blank template, write your code, configure your props, test manually. Developer-centric from start to finish. The V2 Component Builder assumes you might not know what you are doing, and that's okay.

So how does it work?

• AI generation first: Describe what you want. The builder uses AI to generate a starting point. You're editing and refining, not starting from scratch.
• Visual preview always visible: Every change reflects immediately. No save-and-reload cycle. No wondering if it works. You see it working (or not) in real time.
• Built-in testing: Define test cases directly in the builder, like "When I click this button, that should happen." The system validates your component against your expectations.
• Console integration: Errors and logs appear right there in the builder. No separate DevTools window. No context switching. Everything you need to understand behavior in one place.

The Builder was essentially an IDE designed for component creation, optimized for people who might not think of themselves as developers.

Test Runner: Quality Without QA Departments

Of course, enterprise customers are worried about AI-generated code quality. "How do we know it actually works?" Well, we built testing directly into the component model. A V2 component includes not just code but also test specifications. Define inputs, define expected outputs, define behaviors that must hold.

When you deploy a component, the Test Runner executes all specs. Failures block deployment. You can't ship broken components, no matter who (or what) created them.

This shifted the quality conversation. Instead of "did a developer review this?", the question became "does it pass the tests?"

Tests are objective. Tests can evaluate AI-generated code just as well as human-generated code. Tests scale.

The Rollout System

Even if a component passes tests, you might not want to deploy it to everyone immediately. So the V2 rollout system gives unprecedented control:

• Percentage rollout: Start at 1%, watch metrics, increase to 10%, watch more, and so on. Problems surface before they affect most users.
• Segment rollout: Roll out to internal users first. Then beta customers. Then free tier. Then paying customers. Risk increases as rollout expands, so you verify at each stage.
• Automatic rollback: Define health metrics such as error rates, load times, and conversion rates. If metrics degrade beyond thresholds, the system rolls back automatically. No human intervention required.
• Schedule rollout: Deploy at 2 AM when traffic is lowest. The system handles the timing; you just specify when.

This is deployment-as-configuration. You described what you wanted to happen, and the system made it happen. No deploy scripts, no midnight launches, no fingers crossed.

MCP: The AI Integration Layer

The Model Context Protocol had been emerging as a standard for AI systems to interact with external tools. When Anthropic published the spec, we saw immediate relevance for a Myop MCP Server.

What if AI assistants could deploy components directly? Not generate code for a human to deploy, but actually deploy them. As in, create the component in Myop, configure it, and make it live without any human intervention.

So we built our own MCP integration:

• List components: "What components exist in the pricing experiment?"
• Upload components: "Deploy this banner I just generated"
• Configure targeting: "Show this to users in California"
• Check status: "Is the new hero section live?"

This MCP integration means AI isn't just a code generator anymore. It's a deployment agent.

A designer can work with Claude, Cursor, or any MCP-compatible AI, create a component through conversation, and deploy it live in production without ever leaving their AI interface.

This is the future we saw when we heard that designer's question. AI generates, Myop deploys, humans supervise. The loop from idea to production could happen in minutes, not days.

The CLI for Developers

While V2 empowers non-developers, it doesn't forget developers. The CLI gives them power-user access:

• Local development: Run a Myop dev server locally. Edit components in your preferred editor. See changes hot-reload in your browser.
• Version control integration: Export components as files. Commit them to git. Review in pull requests. Import back to Myop.
• Scripted deployment: Build CI/CD pipelines that deploy Myop components. Automate everything that can be automated.
• Bulk operations: Update dozens of components with one command. Search and replace across configurations. The operations that are tedious in a UI become trivial in a CLI.

The CLI is also a debugging tool. Inspect component configurations. Test targeting rules. Simulate user contexts. Everything the dashboard could do, the CLI could do faster for those who preferred terminals.

React Native: Making Mobile First-Class

Until now, web has been our focus. But enterprises increasingly needed mobile support.

"We can't have two component systems," a retail customer told us. "One for web, one for mobile. It's unsustainable."

React Native integration made mobile a first-class target. The same component configurations deployed on web could deploy to native apps. The same experiences, variants, and targeting worked across platforms.

Mobile was technically challenging. React Native isn't just React. It has its own bridge, its own rendering, its own performance characteristics. We couldn't just reuse web components because we needed native-aware rendering that still respected Myop's management model.

The result was a separate SDK for React Native that shares the management layer with web but has mobile-specific rendering. Create a component once, configure it once, deploy it to web and mobile simultaneously.

The Dashboard Running on Itself

There's no better way to validate your product than using it yourself. V2's dashboard was built with Myop V2 components!

The home page? A Myop component. The component editor? Built with Myop's own editor components. Navigation, notifications, and onboarding - all dynamically loaded, all manageable through the same system our customers used.

This wasn't just dogfooding. It was proof of architecture. If our own dashboard could run on Myop, so could any application.

It also meant we could iterate on our dashboard at Myop speed. Found a bug in the home page? Fix it, deploy it, done. No release cycle, no coordinated deployment. Just change the component.

The Browser Extension

With all that glorious MCP goodness out in the world, we could have sat back and chilled. But we decided to take things a step further with the new Browser Extension.

Debugging requires understanding context. What component is showing? What variant was selected? Why this component and not that one?

The V2 browser extension provides a kind of x-ray vision for on-page Myop components:

• Overlay mode: Highlight Myop components on any page. See their boundaries, their names, their configurations.
• Inspector: Click a component to see its full details. Props, targeting rules, variant allocation, everything that determined what you're seeing.
• Time travel: See what the component looked like before. Replay variant selection decisions. Understand how you got to the current state.
• Cross-frame visibility: Even components in iframes could be inspected. The extension sees through frame boundaries that normally obscure debugging.

For developers integrating Myop, the extension became indispensable. For support teams helping customers, it was the first tool they reached for.

Lessons from V2

As always, there are many lessons learned from building your own tools. Here are my big takeaways from managing this latest release:

• AI changes everything. When generation is free, distribution becomes the constraint. Building for AI-generated components required rethinking our entire model.
• Guardrails enable freedom. V2 gave more people more power to deploy. This only worked because tests, rollouts, and automatic rollbacks provided safety nets.
• Dogfooding validates architecture. Running our own dashboard on Myop proved the system could handle complex, real-world applications.
• Multi-platform is necessary. Enterprises don't separate web from mobile. Our product couldn't either.
• Developer tools still matter. Empowering non-developers doesn't mean ignoring developers. They need their own tools like CLIs, extensions, and APIs to work effectively.

What Comes Next

Looking back at seventeen months of development, from that first prototype to V2 with MCP integration, the transformation is remarkable. But it's clear we're at the beginning, not the end.

AI capabilities are advancing rapidly. The components AI generates today will seem primitive in a year. Myop needs to advance with them by offering better sandboxing, smarter validation, more powerful composition, and much more.

Mobile is fragmenting. React Native is here today, but Flutter is growing and others might join the game. Native iOS and Android development isn't going away. Each platform needs proper support.

Enterprise requirements keep expanding. Compliance frameworks multiply. Security requirements tighten. Myop needs to stay ahead of enterprise expectations.

Through all that, our vision remains constant: dynamic UIs that evolve without code deployments, managed by the people closest to the user experience. The implementation keeps advancing.

From init to V2. From prototype to platform. From a frustrated CTO's idea to a product serving companies worldwide.

What will 2026 bring? More frameworks. More platforms. More AI integration. More enterprise capabilities. The roadmap is full.

But for now, we ship. And tomorrow, we ship again.