A visual designer for Spring Boot APIs: model entities and services on a canvas and export a project that compiles —a single service (monolith) or several that talk to each other (microservices).
apigen generates from a schema, but deciding how the system is structured —what entities exist, how they group into services, what talks to what and over which protocol— is easier to reason about by seeing it than by writing it. apigen Studio is that visual layer, and it works the same for a single service (monolith) as for several services talking to each other (microservices).
The model is built on a canvas (React Flow with ELK auto-layout): entities and services as nodes, relations and service-to-service connections as edges, with synchronous (REST/gRPC) and asynchronous (Kafka/RabbitMQ) connections drawn differently. Gateway routes and messaging configuration are edited in separate panels, not on the canvas. On export, each service is sent to the apigen backend and comes back compiled; the result is packaged into a single multi-service project.
Single developer. Started January 20, 2026 — two days after APiGen pivoted into a full code generation platform. Designed every screen, wrote every line. 440 commits in 18 active days; the project shipped in a short, intense sprint.
I took bootify.io as the reference. The single-app generation flow it offers is clean and useful, but the moment the question becomes "how do these three services talk to each other?" the tool has no answer. That gap is exactly where the work that matters happens.
Studio was built to fill that gap. The entity modeling is the table stakes; the microservices designer is the point.
The most consequential product decision. Studio is not "bootify.io clone". It adds a service-to-service designer: multiple services on one canvas, connections between them, a gateway route designer for HTTP routing and an event/message designer for async flows —both in dedicated panels, separate from the canvas—, and a multi-service export that emits an architecture, not a single project.
That is the differentiator. The entity editor is the entry point that feels familiar; the microservices designer is what makes Studio worth using once a team grows past one app.
Tradeoff: scope. A single-app generator is a tractable product; a multi-service designer is much larger surface area. More features means more places to break, more interactions to validate, and more decisions to design. The bet is that the depth pays back on architectures with three or more services.
When there are relations between nodes, Studio uses ELK for layered graph layout. When there are not, it falls back to grid placement. The same approach applies to service-to-service maps. Layout is part of the product logic — predictable, deterministic, repeatable across imports — not a cosmetic pass at the end.
Tradeoff: layout coupling. Changing the layout algorithm becomes a product-level change, not a CSS tweak. The upside is that two users importing the same OpenAPI file see the same layout, which makes review and collaboration possible.
All editing, validation, and preview runs in the client — no backend round-trip while modeling. Zustand stores manage editor concerns separately; Zod validates imports and project structure; React Flow drives the canvas.
Persistence is the safety net. Autosave to IndexedDB on every meaningful change. Snapshot history retained per project so users can roll back. Pre-import safety snapshots so a destructive import can be recovered if the merge goes wrong. The principle: client-heavy is fine when no work can be lost.
Mantine 8 as the UI framework. It is well-built and shipped the product fast, but it ties the editor to its design conventions and components. A more headless approach (Radix + a custom design system, or MUI with deeper theming) would have given more freedom to build editor-specific patterns — denser toolbars, more controlled focus management, layout containers that match graph editing better.
The README has a justification for Mantine; in retrospect the tradeoff was real. The product moved faster early on and pays a bit of a tax now whenever the editor needs UI patterns that fight Mantine's defaults.
Browser-only application, no custom backend:
Let's talk about your next project, or dig deeper into my experience.