Claude Critic Review

0Executive Summary

Reaktor is a genuinely ambitious vision: a graph-based IDE that unifies architecture visualization, runtime debugging, deployment, analytics, and AI code generation into a single tool for Kotlin Multiplatform apps. The technical intuition is sound — the "typed graph as source of truth" abstraction is powerful, and the existing graph/port/visitor infrastructure in the KMP codebase is real.

But ambition without ruthless scoping is a death sentence for small teams. This review identifies 11 categories of risk that, taken together, make the current plan structurally unlikely to succeed on the stated timeline with the stated resources.

This is not a dismissal. It's a calibration exercise. The question isn't whether Reaktor is a good idea — it is — but whether the plan is honest about what it will take.

1The Scope Problem

What Reaktor promises to be

The documents describe Reaktor as a tool where "every person involved in building an app — developer, architect, PM, QA, DevOps, marketing, analyst — can see, understand, modify, deploy, and measure the entire application." This is compared to Unreal Engine's editor.

Let's count the distinct product surfaces this implies:

Each of these is a product in itself. The Graph screen alone — with pan/zoom, port-anchored edges, overlay filtering, hover tooltips, group nodes, and keyboard navigation — is a multi-month project for a dedicated team. The analytics dashboard competes with Datadog. The deploy view competes with Vercel. The AI agent competes with Cursor.

The "everything connects to everything" trap

Reaktor's architecture means you can't ship any surface in isolation. The Graph screen needs the graph model. The DevTools screen needs runtime tracing. The Deploy screen needs CI integration. The Insights screen needs telemetry. The AI agent needs the command schema. Each screen depends on 2-3 infrastructure layers that don't exist yet.

This creates a "big bang" delivery problem: nothing is valuable until everything works together. That's the opposite of how successful developer tools are built. VS Code shipped as a text editor. Figma shipped as a design tool. Datadog shipped as a monitoring tool. They expanded from a working core. Reaktor's plan delivers the entire surface area simultaneously.

2The Timeline Contradiction

The project has two timeline documents that contradict each other:

For reference: JetBrains spent years building Fleet. Jetpack Compose took Google 4+ years from announcement to stable. Figma took 3 years to reach its first public release with a 10+ person team. None of these attempted the breadth Reaktor claims in 60 weeks.

3The Team-Scope Mismatch

The project has 3 contributors:

The workbench is effectively a single-person project. Shibasis is simultaneously:

• Maintaining the Reaktor KMP framework (24 modules, 144K lines)
• Building the BestBuds consumer app (the first customer of Reaktor)
• Designing and building the Reaktor Workbench
• Building the Tactile design system
• Creating the web prototype and documentation

The AI-assisted development argument ("Claude/Gemini write most of the code") is tempting but misleading. AI tools can generate boilerplate and implement well-specified components. They cannot make architectural decisions, debug subtle cross-module interactions, write integration tests, handle production incidents, or maintain coherence across 24 modules. The bottleneck is not typing speed — it's decision bandwidth.

4The Market Size Question

KMP is the initial target

The roadmap targets the Kotlin Multiplatform ecosystem, estimated at ~100K developers by 2026. But Reaktor doesn't target all KMP developers — it targets KMP developers who:

• Use the Reaktor framework specifically (currently: 1 app)
• Want a visual graph-based IDE (a niche preference)
• Are willing to adopt an alpha-quality tool from a 3-person team
• Will pay $29-199/month for it

The addressable market at launch is realistically in the single digits. The roadmap acknowledges this: Phase 1 success metric is "1 active developer" (the creator). Phase 2 targets "5-10 alpha testers."

The chicken-and-egg problem

Reaktor (the framework) needs developers to adopt it. The Workbench needs Reaktor apps to visualize. The Workbench is the selling point for adopting Reaktor. But the Workbench doesn't work yet. And Reaktor (the framework) has one consumer app.

This circular dependency means neither the framework nor the workbench can grow independently. You need both to be good simultaneously, which doubles the development burden on a team that's already overextended.

5The Competitive Claims Are Overstated

The "only tool with every checkmark" claim

The competitive analysis presents a 14-capability matrix where Reaktor has a checkmark in every row. This is misleading because:

• Most checkmarks represent plans, not implementations. Deploy/CI dashboard? Doesn't exist. Analytics/telemetry? Doesn't exist. AI code generation? Doesn't exist. Command pattern? Design only. Cross-platform? The Compose/JS target is commented out.
• The capabilities are chosen to favor Reaktor. The matrix doesn't include: time-to-productivity, community size, documentation quality, third-party integrations, stability, or production readiness — all areas where competitors dominate.
• Competitors are evaluated on their current shipping product; Reaktor is evaluated on its roadmap. Comparing Cursor's shipping AI to Reaktor's planned AI is not an honest comparison.

The "AI tools don't understand architecture" thesis

The central competitive argument is that AI coding tools (Claude Code, Cursor, Codex) work with text, not architecture, and that Reaktor's graph provides the missing semantic layer.

This was a stronger argument 12 months ago. Today:

• Claude Code already reads project structure, dependency graphs, and test results as context
• Cursor indexes entire codebases and understands cross-file dependencies
• AI agents can already run builds, read stack traces, and navigate code structure
• MCP servers for IDEs, databases, and cloud services already exist without requiring a specialized graph model

The gap Reaktor aims to fill is narrowing from the other direction. The question is whether the gap closes before Reaktor can fill it.

6Architectural Risks

The GraphManifest doesn't exist yet

The entire workbench depends on a KSP-generated GraphManifest.json that maps the app's architecture into a typed graph. This is described as the "Phase 1 foundation." The reaktor-graph-ksp module — the compiler plugin that generates this manifest — does not exist.

This is not a small gap. KSP plugins that accurately extract architectural information from arbitrary Kotlin code are extremely hard to build. The plugin needs to:

• Identify all entity types (screens, services, actions, routes, stores, etc.) from annotations or conventions
• Resolve cross-module dependencies at compile time
• Track port connections (ConsumerPort/ProviderPort bindings) across the dependency graph
• Handle generics, type aliases, expect/actual declarations, and platform-specific code
• Generate a complete, correct graph that stays in sync as code changes

The port system is the core — and it's unvalidated

The analysis document itself admits: "The entire ConsumerPort/ProviderPort system — the core of Reaktor — has no visual representation." Port pins in the prototype are "decorative." The graph connects node-to-node, not port-to-port.

This means the most fundamental architectural decision — that applications are graphs of typed ports, not just boxes with arrows — has never been validated visually. The team doesn't yet know if port-level granularity helps users or overwhelms them. If it overwhelms them, the entire "typed graph" differentiator collapses into a standard dependency diagram that many tools already provide.

Live runtime connection is hand-waved

The roadmap describes live telemetry, runtime tracing, and real-time graph updates. But the prototype is 100% static data. The architecture for streaming runtime data from a KMP app into the workbench doesn't exist. This requires:

• An instrumentation layer in the running app
• A communication protocol (WebSocket? gRPC?)
• A state synchronization mechanism
• Performance isolation (the observer can't slow down the observed)

Each of these is a multi-week project. Together they constitute an infrastructure layer as complex as the workbench itself.

7The Prototype Paradox

Beautiful but dangerous

The web prototype at reaktor.build is visually impressive: dark IDE aesthetic, resizable panels, sparkline charts, causal traces, heatmaps. It looks like a shipping product.

This is a double-edged sword:

• It sets expectations the team can't meet. Anyone who sees the prototype expects the real product to look and feel this good. But the prototype is a React facade with hardcoded data. The real product will be Compose Desktop, which has worse text rendering, less mature animation APIs, and no CSS. Recreating this visual fidelity in Compose Desktop is a massive effort.
• It creates an illusion of progress. 6,100 lines of JSX is impressive output. But it's throwaway code — the documents explicitly say "don't try to preserve this codebase." The real progress toward a shipping product is measured in the KMP modules, where the picture is much thinner.
• The spec coverage is self-reported at 35%. Even as a specification document, 65% of the intended behavior is unspecified. The prototype defines the happy path for 5 screens but doesn't address error states, loading states, empty states, permission boundaries, or data pagination.

8The AI Integration Bet

MCP as moat — how defensible is it?

The competitive thesis positions Reaktor's MCP server as a unique "semantic layer" that makes AI tools architecturally aware. But MCP is an open protocol. Nothing prevents:

• JetBrains from building an MCP server that exposes IntelliJ's code model (they have a richer one)
• Android Studio from exposing Compose's component tree via MCP (Google has the resources)
• AI tools from building their own architectural understanding without MCP (they're already doing this)

The MCP moat depends on Reaktor's graph model being significantly better than what IDE vendors can build. Given that JetBrains has spent 20+ years building code analysis for Kotlin, and Google controls the Compose compiler, this is a bold assumption.

GraphCommand as AI interface

The idea that AI generates structured GraphCommand objects instead of raw code is elegant in theory. In practice:

• LLMs are trained on code, not on Reaktor's custom command schema. Fine-tuning or heavy prompting is required.
• If the command schema is too constrained, the AI can't express complex changes. If it's too permissive, you've reinvented "write code."
• The command system adds a translation layer between intent and code. Every translation layer introduces bugs, latency, and cognitive overhead.
• Developers who are comfortable with AI-generated code may not want the indirection of a command layer.

9Business Model Concerns

Pricing assumes value that doesn't exist yet

The revenue model depends on reaching Phase 4+ before generating meaningful income. At $29/month for 5-10 alpha testers (Phase 2), that's $145-290/month in revenue — roughly 0.1% of a single engineer's fully-loaded cost. The business is not self-sustaining until Phase 5-6 with hundreds of paying users.

The open-source tension

The framework modules are open source; the workbench is commercial. But the workbench's value depends on the framework having a large user base. If the framework doesn't grow, there's nobody to sell the workbench to. If the framework does grow, contributors may build open-source alternatives to the workbench (the graph model is public).

This is the classic open-core tension, and it's harder to navigate when the open-source layer has minimal adoption.

10Existential Risks

What if KMP doesn't win?

Reaktor is deeply coupled to Kotlin Multiplatform. If KMP's adoption plateaus (it's still a fraction of Flutter's user base), Reaktor's addressable market stays small. The plugin architecture (Phase 6) promises framework-agnostic support, but by then the product needs to have been self-sustaining for 30+ weeks on KMP revenue alone.

What if the graph model is wrong?

The entire product is built on the premise that a typed architecture graph is the right abstraction for application development. But most successful developer tools are not graph-based. IDEs are text-based. Design tools are canvas-based. CI tools are pipeline-based. The graph abstraction is popular in game engines (Unreal Blueprints) and workflow tools (n8n), but it's unproven for application architecture.

If developers prefer reading code over reading graphs — and decades of evidence suggests they do — the entire product premise is invalid regardless of execution quality.

What if one person gets sick?

With effectively one person building the workbench and framework, any interruption — illness, burnout, life events, a day job conflict — stops all progress. There's no redundancy, no institutional knowledge beyond one person's head, and no onboarding path for new contributors (the codebase spans 24 modules across 3 repositories with a custom build system).

11The Steel Man — What Could Go Right

A devil's advocate review is only credible if it acknowledges the genuine strengths. Here's what Reaktor has going for it:

12Risk Scorecard

Recommendations

If the author were to ask "What should I do differently?", here are the highest-leverage changes:

1. Ship GraphManifest first. Before any more UI work, build the KSP plugin that generates the graph from real code. This is the foundation everything depends on. If it can't be built, know that now.
2. Cut the MVP to Graph + DevTools. Two screens, one inspector, no AI, no deploy, no insights. Prove that the graph visualization is valuable to at least 5 developers who aren't you.
3. Stop claiming shipped features that are mockups. The competitive matrix should distinguish "shipped," "in progress," and "planned." Developer trust is earned through honesty, not feature count.
4. Find 2-3 external KMP developers to test with. The biggest unknown is whether the graph abstraction resonates. Test this with real users before building 13 inspectors for a model nobody has validated.
5. Reconcile the timelines. Pick one number and build a plan that's honest about it. A credible 6-month plan for a focused MVP is better than a 60-week plan for everything.
6. Address the bus factor. Write an architecture guide. Record decision rationale. Make it possible for someone else to contribute.