Magic Patterns

The trait that decides it is the screenshot import. Feeding it pictures of your existing product and getting prototypes that look like they belong there is the difference between a mock somebody argues with and a mock somebody tests. For a product team validating an idea on Tuesday, that fidelity is the entire value.

It is a prototyping tool, so treat what comes out as a conversation, not a foundation, and expect the real implementation to start over. Pick it if you are testing ideas before anyone commits engineering time. Pick v0 if you want output you will actually ship.

The gap is disclosure. No backbone model appears anywhere on the material, and there is no mechanism to point it at one you have already vetted. So the thing writing your interfaces is unnamed, its behaviour can change between Tuesday and Thursday without notice, and a regression in output quality has no explanation you can investigate.

Screenshot uploads of an unreleased product go into that same undisclosed pipeline, which is worth noticing before the design team starts uploading. What it does right: designers and engineers share a workspace, so the handoff is a link rather than an exported file and a meeting.

1. Context gathering is two inputs: a natural-language brief and screenshots standing in for a design system. 2. There is no planning artefact between input and output that a reviewer could inspect. 3. Verification is entirely human, since the success criterion is whether a designer recognises the result as theirs.

That criterion is subjective, which is defensible for a prototyping tool, but it means fidelity claims are unfalsifiable as stated. There is no documentation site and no verification date on the listing, so nothing else can be assessed. One observation: matching a design system is a measurable task that nobody chose to measure.

The position is smart and precarious in the same breath. It occupies the step just before design, which is upstream of an incumbent with near-total distribution among the people who would buy this. Enterprise terms are custom, the standard tell that the published tiers are a funnel and the real contracts are negotiated one at a time.

Moat: workflow habit inside product teams, which is shallow against an incumbent shipping the same feature natively. Likely acquirer: the design tool it currently sits upstream of, which is also the most likely competitor. Position: a feature with a good year in it, not a company with five.

Sixty seats at the business price is $6,000 a month, which would be absurd for a tool only product and design will open. Bought correctly this is eight seats at $20 or a handful at $100, and the free tier lets me establish which before signing anything. That is the whole procurement conversation.

Directory integration, audit trails and retention terms are not documented, and screenshots of unreleased work will be uploaded, so those become questionnaire items. Nothing here touches our pipeline. Onboarding is an afternoon for a designer. Approved with conditions: a small named group, no customer data in uploads.

There is no source, no local option, no configuration file and no way to route it at a provider I trust. Everything happens in a browser tab against infrastructure I cannot inspect, which means when it behaves oddly my only recourse is a support form. That is the opposite of ownership in every sense I use the word.

One grudging concession. What it emits is ordinary TypeScript, HTML and CSS, not a proprietary document format, so the artefact at the end is portable even though the tool producing it is not. That is a lower bar than it sounds, and it is the only one cleared here.