I don't normally comment on these things, but I gave it a quick shot for a project I'm working on (fairly generic dashboard-style prompt, but that's fine).
I'm actually pretty impressed. A couple things though:
1. It took a _while_ to give me anything. Not sure if that's related to load, but it was ~17 files, and probably took 5+ minutes. It was not clear what was going on in that time, or what would happen if I left it. I literally left my machine to go something else before coming back.
2. I really hate saying this, but your pricing is probably way too low, especially at the "pro" level from your pricing page. When stepping into team-based config management and pre-sets, you're leaving a ton of money on the table without enterprise-style custom value-based pricing. If you were asking me, I would recommend moving the team based features (shared presets, custom access control, etc) into an "enterprise" level above pro).
I'm not going to comment on any sort of "correctness" as far as any complex UX behaviours or workflows; I'm only considering this from a mockup/design/demo-of-new-ideas perspective.
1. We're using Sonnet 3.7 for the first prompt. I've noticed with some prompts that require lots of files it can be PAINFULLY slow. Our servers also might be getting slammed from the HN traffic. We have a "fast" mode that uses 3.5 that you can toggle and that's the default for editing, however, it won't be as visually rich. We need to improve the loading experience for sure. One big UX/UI difference between our product and others is that our preview is always shown versus on other tools the code is always shown. Other tools will stream in the code to mask the load time. We used to do that, and will likely bring it back.
2. Re pricing - that's the most important feedback we'll hear all day! We used to have a "contact us for pricing" tier, but have found self-serve a lot more effective and easier to scale.
We actually still only 2 people, just my co-founder and me. When you say "custom value-based" are you referring to a "contact us for pricing" tier?
> When you say "custom value-based" are you referring to a "contact us for pricing" tier?
Ya. Not saying that it's applicable to everyone (or even most people), but really once a team gets above maybe 20+ people actively using this, they're not going to blink at $1200/month (good for you now, but you'll be leaving a ton of money on the table, and it's hard to adjust expectations later).
Maybe capping the size of a team on the "pro" plan would be an inbetween, but it's something to talk to your customers about.
Happy to chat more directly; my email's in my bio.
> Maybe capping the size of a team on the "pro" plan would be an inbetween
That's interesting. We already have teams with 20+ folks on it today at very large companies, but haven't thought about that type of stuff too much - have been laser-focused on core product building. I think in the early days we spent a little too much time tweaking minor pricing plan details. You're right though we are now at a point where we are very likely leaving money on the table.
For example, "centralized billing" on our platform only exists because it was the result of a feature request from a larger customer.
This is super cool—love how you’re flipping the AI-assisted creation story to focus on design-first workflows. The frontend-only scope is such a smart constraint, especially for PMs and non-designers trying to validate ideas fast without diving into fullstack territory.
I’ve seen firsthand how hard it can be for non-designers to clearly communicate product ideas, and Magic Patterns seems to lower that barrier in a really meaningful way.
I noticed the GitHub Sync option—curious how teams are using that today. Is it more of a dev handoff (e.g. PR previews) or a starting point for custom builds? Would love to hear how that fits into engineering workflows—especially for folks skipping Figma entirely.
Also really appreciate the collaborative angle. Real-time team prototyping on a canvas feels like the future of internal product reviews.
Rooting for you both—this is such a focused and thoughtful approach to a real gap in the market.
The Github sync is used by solo entrepreneurs or hobbyists to get what they've designed in Magic Patterns into their IDE. 99% of the time that's an AI-IDE, like Cursor. And then from their they might add backend functionality. It's pretty interesting seeing how Cursor is the "next step" after these types of tools for that persona.
On the other hand, for product teams with mature engineering workflows, it usually goes like this:
1. Designers/PM brainstorms an idea in Magic Patterns
2. They get feedback in a design crit or from their users by sharing the Magic Patterns URL.
3. They iterate on it further and then either export it to figma or hand it off to engineering directly. But! engineering won't use the code because we output React + Tailwind CSS, and they are very likely using custom components or have their own nuances.
I do think as the foundational models get better the dev/design handoff will get smoother, but I don't think we are there yet, especially for existing code bases. For new projects, it's a different story and our two-way Github sync plays a role.
I used magic patterns for a couple of months and it was one of the first no brainer AI services I've paid for outside of the main LLMs and IDEs. It did such an amazing job on quite an esoteric frontend that's very much not your normal web app. Impressive. Next time I need to design and build some more frontend code I'll be subscribing again.
Edit: to add some meat to that comment what surprised me was just how much better it was than Anthropic and OpenAI tools at that time for coming up with great looking products with minimal prompting. I also fed it other designs for inspiration and it replicated them brilliantly while incorporating my requirements. Good stuff.
```
create a Rubik's cube app with all available moves and show the cube and the animations. add a scrambler and a solver. Also add timer to time the moves.
```
Which looks like a good starting point but doesn't work at all. After this it is daunting to look at code. I still have to figure out how to tell the chatbox to fix it.
Gemini 2.5 pro did much better in one shot. (the prompt was different and without the scrambler/solver/timer)
Do you have the prompt you used for Gemini 2.5 pro? I think it would be interesting comparing prompt for prompt!
In this case, it looks like the Gemini output that you linked — as you mentioned — doesn't include the requirement for a scrambler/solver/timer, so it's hard for me to comment directly on the comparison.
I ask because we can totally add Gemini 2.5 pro as one of the models we use under the hood!
Well, I was not comparing but it was just an observation.
I understand Magic has more constraints on which libraries it can use and probably is for forms-flow kind of workflows and not for managing complex states of games.
That's pretty cool! Thanks for sharing. I like how Gemini used pure HTML/CSS to start.
While we certainly do constraint it, it still should be able to manage creating a Rubik cube solver (even though that is definitely not the intended use case).
There's a lot of work around UX and how you interact with the LLM. For example, given an entire React app + a user prompt to update it, which code snippet do you feed to the LLM? The LLM cannot read your mind. In a way it feels like the application layer's job to help it read your mind.
You probably know this, but just want to say, founder to founder: don't listen to this argument at all.
People are so fond of saying "just wait and the new model will do this." And very smart people I know say it (especially when they work for OpenAI or Anthropic!).
It might be partly true (of course it's situational). But it's a glib and irrelevant thing to say. Model capabilities do not advance like some continuous exponential across all domains and skills. Not even close.
Product design is exploring the solution to human problems in a way that you can bundle and sell. Novel solutions to human problems tend to come from humans, applying effort over time (with the help of models of course) to understand the problem and separate out what's essential and what's irrelevant to the solution.
> "The hard part of being an engineer is not writing JavaScript. It is building a solution that addresses the essential complexity of a problem without adding accidental complexity."
I have been oversimplifying it as "LLMs cannot read you mind."
Do you not think that’ll get solved by a future generation of cleverer LLMs though? As someone pointed out in another comment, they get better results with Gemini 2.5 already.
People already seem quite annoyed with Cursor based on that thread the other day with the hallucinated customer support.
Okay, I'll bite. My issue w/ statements like "building something an LLM will do in the future" is a constant goal-post moving argument.
It seems to equate to "how is this getting funded when AGI is going to do it eventually anyways". That applies to literally everything. "Why bother building a social media platform, soon an LLM will be able to build an entire one in a day!", "Why bother becoming a plumber, soon an LLM will be able to control manufacturing equipment to build a robot that can do it better than any human", "Who needs architects, LLMs will soon be able to design perfect buildings for whatever use case!".
If your point is only that some companies are currently getting funded that are a weekend-project away from getting Apple-d out of existence, then I would definitely agree that some companies are like that (just like some app companies were like that 6 years ago). Some companies are just super basic wrappers around someone else's LLM, but the expectation (from investors, at least) is that there's a bigger goal and the "easy weekend project" approach is for validation and building some sort of user base now.
However, I also disagree that this is the case here. Building good UX's around LLM usage is not just "using LLMs", and figuring out the use cases people actually want is also not just "using LLMs".
100% agree. There is a bigger point too: People assume LLM capabilities are like FLOPs or something, as if they are a single number.
In reality, building products is an exploration of a complex state space of _human_ needs and possible solutions. This complexity doesn't go away. The hard part of being an engineer is not writing JavaScript. It is building a solution that addresses the essential complexity of a problem without adding accidental complexity.
The reason this is relevant is that it's just the same for LLMs! They are tripped up just like human engineers into adding accidental complexity when they don't understand the problem well enough and then they don't solve the real problem. So saying "just wait, LLMs will do that in the future" is not much different than saying "just wait, some smarter human engineer might come along and solve that problem better than you". It's possibly true, possibly false. And certainly not helpful.
If you work on a problem over time, sometimes you'll do much better than smarter person who has the wrong tools or doesn't understand the problem. And that's no different for LLMs.
> Do you not think that’ll get solved by a future generation of cleverer LLMs though?
I don't. But obviously I'm biased + have spent perhaps too much time at application layer. I think there will still be a large amount of tooling + feeding of context to get the best result and I don't see a world in which we let LLMs run hog wild on our computers any time soon, especially for prototyping workflows at the enterprise level.
And for the sake of discussion: let's say these cleverer, future generation LLMs do exist... then I think the entire workflow will be very different. Hard to say how. Perhaps knowledge work as we know it will be unrecognizable.
Re: the Gemini 2.5 comment, I would love to compare it prompt for prompt. Looks like the prompt they are comparing it to didn't include the requirements for the Rubik's cubes scrambler/timer/solver. That said, I wouldn't be surprised if one LLM — Gemini 2.5 in this case — is better at creating a Rubik's cube compared to Sonnet 3.7/3.5 with our system prompt. (Not a lot of product teams are prompting our platform to build Rubik's cube in three.js lol). But if it is better, what's great is we can easily swap it out and start using Gemini.
Model providers will be fungible. Applications will capture all the complicated interaction patterns, domain expertise, and distribution.
Apps can route between cheapest/most effective model. And the Chinese and upstart labs will continue dumping open source on the market. To get distribution, to salt the earth, commodify the compliment, etc.
When will an LLM be able to author a directory of GLB files organized into a game, precisely positioned within a world, with a set of user-tweaked PBR textures? Never. And even if it could, could you fathom the pain? The app layer will do that.
If the company can build a big user base first, then they become a possible acquisition target in the future by the LLM company for their distribution, ala Windsurf selling itself to OpenAI.
How did you manage to advertise or generate initial traffic for something like that?
Even if the tool is excellent, it seems like the space is flooded with “Prototype your app with AI” tools, many backed by big players with huge ad budgets.
The target audience must be getting bombarded with a dozen similar pitches every day. How did you manage to cut through the noise?
I find myself asking this question often, so there’s probably something fundamental I don’t quite grasp about startups in general.
In startup land, I think it's really important you love your customer. Because you cut through the noise by having your existing customers tell their friends about you. 30% of new users hear about us from their friends.
I'll also note: we launched for the first time in October 2023. At the time the space was not flooded. We first got 10 users who loved us — where I define "love" as using us weekly — and since then it's a game of continuous iteration!
This is a very good idea. I see a lot of friction (and lack of process) with product -> UX -> dev than with product and dev able to iterate on things like screen flows very quickly, and UX feeding in more from the user research angle.
Currently a lot of UX work is "translate what you said into Figma and wait for comments" which is very automatable, and I think frustrating for UX people as much as anyone.
I just had a cool experience with it doing some simple design. It prompted back to me usefully as well.
I can imagine also uploading a component library that this thing then uses the components from, to add styling for higher-fidelity designs, and allow app designers/builders to just use the components built by an internal team (who might also use magic patterns, I suppose).
Interesting. So, if you're targeting the PM and only building a frontend, are you actually competing with Figma? With the many use case of creating/iterating a UX prototype?
In which case - you mention that MagicPatterns creates components, but can it also reuse existing components? E.g. sometimes I'd want to create a UX prototype, but use a pre-existing UI / design language to match how my sites/apps are already implemented.
> "I spend 80-90% less time drawing boxes in Figma - and more time using my insights, creativity, and words to create working prototypes [...] - to shorten feedback loops & better communicate vision."
We are rolling out a reusable components feature. If you hit us up in our support chat or email me: alex [at] magicpatterns.com I can add you to the feature flag!
Not using Magic Patterns but absolutely +1 this workflow. I'm a designer working across multiple teams and it's so fast and fluid to get react prototypes out of an LLM. I put together a vite project to drop the resulting typescript files into. Much quicker iteration with PMs and then we capture spec from the prototype. I see this as a way to scale our design efforts across the org since we can get higher resolution iteration done faster.
which tools are you using? And if you do end up trying us, let me know what you'd like to see or if we can help with anything!
It is remarkable how fast pure prompting can get you an interactive prototype.
We recently added the ability for our system to reference markdown files, so one thing you can do is paste a PRD into Magic Patterns and then tell it to reference that PRD as it builds out your spec.
I started out copying and pasting from Claude Pro. Then I hooked up MCP so it could edit files directly in my local repo.
I set up this template with all the shadcn components pre-installed so you can prompt something like, "make a prototype of this mockup using shadcn" and then just drop the page in without any extra importing or routing. https://github.com/pglevy/vibe-coding-boilerplate
We recently got Gemini at work so trying to use that now since everyone has access.
Yay! I like Magic Patterns. It is more useful and accurate compared other tools. I have successfully been able to get some design ideas implemented in it. It seems to understand consistency more than other tools.
In the earliest days of the product, we were hyper-focused on custom component libraries. We connected to Github repos and then fetched the relevant components for every prompt. We no longer do that because the models got a lot better and most customers don't care about the code, they care about the visual output. But this lead to us always caring a lot about consistency. Still iterating on that every day.
There were some comments on pricing that I'd like to comment on: As a one man startup that's fully self-funded I deeply appreciate the prices that aren't straight out of Sillicon Valley. I believe in free market and really don't mind companies doing profit first, but those are often services that simply are out of reach for the more budget conscious of us while adopting new technologies.
Let me thus petition for keeping a small enterprise plan in the price range you're now at, maybe limited by nr of employees, company age, and/or even easier, the number of subscription months/years. That'll give us a chance to adopt your service while increasing the value we get from the service.. When the value's there I won't hesitate to pay a higher price for it either.
> or even easier, the number of subscription months/years.
We do offer 20% off on annual plans! ;)
We're very proud to be largely self-serve and have pricing that is completely transparent right now. Of course, we're open to feedback on pricing, especially enterprise pricing, which is why I was intrigued by the other comment.
And I agree, I think most people forget that a push back on price is really a push back on value, and so the value needs to be there first.
Canvas is an interesting idea - although the implementation feels very clunky and half finished.
rest of the tool doesn't feel that special - eg there's tonnes of code generators out there. would have to play more to understand but it wasn't immediately apparent
We always iterating and definitely need to improve! Anything you can point to explicitly that makes the canvas feel clunky/half finished? We're using a simple div under the hood!
To add some color: while we do generate code, we don't view ourselves as a code generator because our customers don't get value out of our tool from the raw code. They instead receive value from the interactive prototype, and for that reason it's lot of PMs, designers, founders using us versus developers.
I gave it a shot to iterate on our current UI. It did try to solve the problem we were focused on, but it also randomly removed other features that we hadn’t touched or even talked about. This makes me believe there will be a lot of back and forth that is low value just correcting small details. In UX/UI details really matter. I'd probably opt to just move pixels around my self in this case.
If this were a brand new project with no existing UI at all and we just needed to spin up a quick prototype, I think it’d be great for that. And honestly, I do think LLMs will end up playing a big role in UX design over time—so this is definitely in the right direction.
But for real-world use cases where the UI already exists and quality or timesaving matter, it doesn’t feel like the right fit yet.
Our largest customers generally use us to prototype brand new UIs versus existing ones, so you're spot on.
We're certainly better at new UIs versus existing UIs. Existing UIs are tough because you need to first recreate what you have in the codebase first. This is a large reason why we built a Figma-like canvas (https://www.magicpatterns.com/docs/documentation/projects/ge...), so that you can reference existing designs to make new ones.
So, for example, you could make your navbar, button, dashboard, and then click on that and reference it to make another design.
P.S. if you're open to it, open a support chat or DM me? Would love to help you get more value and see what prompts are causing it to remove stuff. It can also be really frustrating when it removes features — what can be helpful is going back a version or also editing the code by hand. We've had code edit since day 1. Totally aligned everything needs to be a prompt to get the small details right.
i recently used Magic Patterns for a very niche use case and had a great experience:
i wanted to do show new customers examples of how they can use my product, which lives primarily in email.
to do it via Loom I would need to create tons of fake email addresses and juggle a whole complicated set of scenerios. and to do it in after effects would take forever.
Yes, it's incredible seeing what you can do with pure code. I think that's a lot of the magic here: with code, you can do anything. This part is super gratifying to work on.
From day 1, we have thought of code as a first-class citizen in Magic Patterns because that's all the LLM sees. So then at the application layer, it becomes our job to best help the user interact the LLM a.k.a feed it the most relevant code. This part is suuuuuper challenging.
The biggest difference is that we only do frontend, and that's very intentional. There's no database provisioning, no integration with an auth provider.
At first this may sound like a disadvantage, but it helps us stay very focused on actual product teams and their workflows.
Examples include: 1. we have an infinite, real-time canvas for collaborating, 2. reusable components and leveraging your existing brand, 3. export to Figma, 4. password protection on designs, 5. feedback collection. These are all features that customers have asked for; we haven't found that product teams need to spin up a database or leverage a Stripe integration.
Last note: this space is absolutely massive and we find all the other tools popping up very motivating. We first launched in October 2023 (before most other tools) when all you could generate with GPT 3.5 was a small React component. Our long-term vision is to be the one-stop shop for frontend.
to add on to Alex's answer above, we also differ in that we have a lot of features focused around brainstorming / exploring ideas, versus just spinning up a fullstack app. For example, we have a "Commands" feature that lets you get four variations (that are guaranteed to be different!) of a prompt.
We also have a Chrome extension that lets you import designs from your existing product to ideate on top of existing content.
Other tools are AMAZING for spinning up actual fullstack apps and use cases that require persistent storage. But actual product teams aren’t asking for that.
Also, our customers tell us that anecdotally it feels like we error less compared to other tools because we are focused entirely on frontend (there’s less room for error). Of course, we still error a lot - not easy when natural language is your input set!! - but it helps to stay focused and theres less dependencies on a backend & database.
p.s. one of my personal favorite parts of Magic Patterns is that you can very easily revert to a previous version, which is possible because no backend or database!
I love the idea. I just tried it for the office software suite I'm building and although I wouldn't copy-and-paste the design it suggested, it gave me a few ideas to iterate on, and that's already useful. I'll explore it further when it's time for more design thinking (I'm pretty set on my current design for now)
Interestingly, part of the value of the project I'm working on comes from bundling an AI assistant so that you can get documents (spreadsheets, presentations, documents) from natural language, so there's some overlap--the obvious difference being I'm trying to build complex documents instead of complex UI
Awesome to hear — our goal is to get to a point where you can copy/paste the design, but we totally recognize that it doesn't always get you to a full high fidelity mock up with the current limitations. So the main use case we've seen a lot of success with is ideating and validating different branches, quickly.
Oh that sounds very neat — definitely similar in nature! Documents and UI are both complex and can require a lot of iterations to get right
FWIW I think it could get a pretty high fidelity mockup if I had spent more time with it! It was remarkably good for a single one-shot prompt which probably had 15 words or less. I'll definitely come back for more when the time is right.
Definitely — we've seen some pretty crazy high fidelity mock ups from our customers who spend hours and hours prompting away, and they genuinely blow my mind. it's honestly why we spend so much time working on the application layer (e.g. making it easier to feed context into your prompt, referencing other designs, etc) since we know that the LLM is capable of these things, it just takes much more time than most people are willing to put in.
would love to hear what you think when you give it another try!
To be honest I was up and running in less than a minute so nothing stands out. I didn't dive deeper right now but if I could do this and export to Figma directly that would be 100% of my use cases right now.
Hey kids, grizzled UI designer and developer at a startup here. You’ve got 2 keys correct right at the start.
1. Permissions/auth for prototypes. Stakeholders go for that. MBA folks don’t want to be sent crazy random obfuscated URLs, they want a nice login page that makes them feel secure. (Because MBA types will get weird about corporate secrets, even just high-level wireframes.)
2. Figma/Miro-esque infinite canvas with comments. Product managers and stakeholders love that flow.
Overall this is impressive for MVP.. I also like the manual click-to-select-objects for more refinement.
I was unable to find the CSS styling code however ( sorry not a React/Tailwind user ) it just showed me index.css like so:
{@import 'tailwindcss/base';
@import 'tailwindcss/components';
@import 'tailwindcss/utilities';}
If it's helpful, the styling will be in the "jsx" file vs the css file! So when you use that "manual click-to-select-objects" feature in the chat bar, you can click on "Highlight Code" and then that will take you to the React component. In that component, you'll see a className field which will have Tailwind classes in it. That's technically what is applying the styling and boiling down to raw CSS.
Ah! Need to clean up what's happening there when using the Chrome extension to import an existing design - pushing up a fix. There's a great discussion on the extension here (https://news.ycombinator.com/item?id=42043552) btw if you're curious how it works.
When it comes to adding images, it works best if you give it an existing image URL or upload an image, which we then host for you. In this case, Sonnet 3.5 appears to have hallucinated an invalid image link. Also need to make this more robust!
hmm having an "Edit Style" for any object, in 1-click ( instead of traversing into component's guts, etc ) will be a more frictionless UX.
in fact just show the same Figma Style UI controllers would be even better since that is a proven UX mental model;-)
I'm interested in understanding your desire to do design and prototyping as a single shot?
My expectation was that I'd iterate on a few UX designs with the LLM and then when I'm happy with what the LLM is suggesting, I'd output to figma, and then maybe move to code.
It's great that you're generating code, but isn't that increasing your cost and processing time to write code for each iteration?
What do you mean by "single shot?" Are you referring to one-shot prompting? I should have clarified in my post — we do have customers who one-shot designs - but that's very rare (it's usually landing pages because Sonnet 3.7 is really good at those). We heavily encourage iteration and expect it. The longest thread on the platform is 850+ messages in a single chat!
We have a fine-tuned fast apply model for applying code diffs, so that helps minimize the processing time. Always trying to make it faster though.
We view code as a way to 1) unlock interactivity, 2) communicate with the LLM.
A question for you: if we weren't asking the LLM to generate code, what would we ask it to generate?
1) as for a certain UX design
2) AI shows me an image of what it thinks I want
3) I make suggestions, changes to what I want
4) AI makes changes, shows me an image
5) back to step 3 and repeat until I'm ready to view code
6) have the AI write the code of the UX once.
I understand this may mean there are multiple images showing a flow, or different states, but in my mind, the time consuming part is the AI creating each JS file for the UX. I would think it could iterate quicker on designs and then output code.
This is how UX is designed today, designer does a bunch of iterations, gets feedback, then hands it to developer.
Right now, you're doing this all at once (or at least that is what my experience was).
I get what you mean about code as a method of communicating with the LLM, and I'm an engineer, so I kinda get that, but my first reaction wasn't "let's look at the code output", I was looking at the design output and thinking "is this what I want?"
I don't think generating images would be faster than generating code, plus you lose all the interactivity. Many designers tell us where they get the most value out of Magic Patterns is that the designs are interactive by default, unlike traditional vector-based design tools.
I'm with you that the first reaction is not "let's look at code output." In fact, for most of our users, they never look at the code. It's abstracted away from them and just an implementation detail to unlock interactivity.
hey thanks! spun that up over the weekend. I noticed another Launch HN did that and thought it was brilliant. we are here for feedback, so wanted to make trying it as easy as possible!
On https://www.magicpatterns.com/ you should see an input box. Type anything you want, hit enter, and then you'll get hit with our regular login panel. But at the bottom, for today online, you'll see a "Coming from Hackernews, no login required" button.
I'm CTO at a startup and Magic Patterns is amazing, my current workflow is to ideate using MP then implement straight to my codebase.
The instant feedback-loop of iterating over components is great and perfect for me when I'm designing a feature that's heavy on the client side of things.
For example it took me half a day to go from idea -> design -> implementation
That's largely how we use it internally too. I often use Magic Patterns first to think through the steps and user interactions, and then I'll jump into cursor to start implementing.
p.s. great to see a customer on here. appreciate it.
This is something I would definitely use, as my company pays for v0 today for these exact purposes (product design/PM).
I've tried some of the same prompts I've done on v0 but didn't notice a lot of difference -- needs a lot of back-and-forth, as with v0. So not sure what would make me switch at this point.
v0 is an amazing product. They've been around as long as we have (October 2023), and it's cool seeing how we have both iterated on the same problems.
Some differences with v0:
- Magic Patterns has a Figma-style canvas for collaborating with stakeholders. Makes it easy to view all your chats.
- Password protection on designs (this is very important for some companies!)
- Feedback collection on prototypes
- Reusable components, so you can create a component library with us and then reference those components in your design.
- We are only focused on frontend, which we think leads to less hallucinations. Also, when there is no database, you can go revert back to a different version of the design at any point.
Why would you limit the tool to strictly be for React?
"As per my limitations, I am designed to work specifically with React and TypeScript/JavaScript only. I cannot provide direct conversions to plain HTML/CSS or other frameworks."
Mainly to narrow the problem space: there's a lot of logic in our backend that we call "post processing" which is cleaning up the code after the AI generated it to
fix hallucinations. For example, the AI often gets import statements wrong or misspells icon names.
It's pretty interesting because every model seems to introduce a new set of hallucinations, so this is a problem that requires a lot of maintenance. We have this internal mantra to "use AI as little as possible" especially it's a problem that can be solved deterministically.
Also, because we are more focused on PMs, designers, and product leaders the code is largely an implementation detail. What they care about is being able to visually communicate their ideas, and React just happens to be a great way to do that because LLMs are great are outputting it + we have a pipeline to render it. (We are React developers ourselves.)
I'm curious, if you have that philosophy (which makes a lot of sense), you must have considered building is a sort of more abstract (but extensible) UI toolkit language and library and you could code in that then compile it down to React? Or have you found the benefit of large LLMs already having detailed React training is just too high?
> have you found the benefit of large LLMs already having detailed React training is just too high?
This.
We've tried a lot. We have been around since Oct 2023. First tried fine-tuning, but it's very hard to teach an LLM something new.
At one point, our product lived in a Figma plugin (https://x.com/Teddarific/status/1729153723728011618). To do this, we had the LLM output JSON, and then converted that to Figma nodes. This is sort of what you're saying. But the big issue was it would hallucinate many things and was really only good at the examples we fed it.
I want something which looks like design for engineers. I'm a programmer, code completion is nice, but I already know how to code. What I am terrible at is design.
I think sometimes people think design is purely making things "look good", but I come to realize it's also making things "work good!" a.k.a making it intuitive. "Don't make people think!"
It's been pretty cool to see how a tool like Magic Patterns is helpful for software builders to think through the flow for whatever feature their building. This is largely how I use it internally. For example, when I added our deploy feature, I first used Magic Patterns to think through what steps I needed to add: https://www.magicpatterns.com/c/d9sb9eavgnpjv1d5vaw6wa
This is long way of saying that one way I have become a better designer is by using AI as a creative assistant, but then also recognizing when to not reinvent the wheel. You also want to leverage existing patterns as much as possible.
oof! this is a bad bug that seemed to tick up overnight! Fixing this, thanks for flagging. If you create a support chat via "Get Support" or DM me happy to throw you some credits and regenerate it for you.
what are the plans to support design systems? no one seems to be able to do this. prototyping doesn't happen in a vacuum, I'll always want to use the design system we spent months building in Figma.
Yes! We have a feature for reusing components where you can prompt "use my @design-library/button." But right now @design-library needs to be re-created in Magic Patterns. This is behind a feature flag, but let me know your account email or DM me alex [at] magicpatterns.com and we can add you to it!
We're looking into importing from Storybook too, but it can get fairly custom and we want to make sure it scales. It gets tricky because these systems are expecting a certain format - in our case React + Tailwind - and so if the design system isn't that, the LLM won't handle it well.
Once you figure out how it can understand all my Figma components and their styles (maybe via some “design”MCP).. it will make me 100% switch my design proto workflow!
What I'll add is we are seeing customers use Magic Patterns + other 'vibe coding' tools in conjunction. For example, they might use Magic Patterns for brainstorming and to think through the design, and then they'll copy the code from Magic Patterns into Replit to "make it real" and add a database or authentication.
This service is pretty much what I, a software developer, am scared off. I expect that it will be used in order to quickly cobble something together and then hand it over to a dev for "polishing". And this sounds like a total nightmare to me.
If used like that, this service will effectively turn my job into that of an assistant to a machine.
It will happen. Product managers will essentially vibe code and make a thing that mostly works before handing it to developers for 'polishing'.
This could go two ways:
Dumb PMs - "I did most it myself in a week, it shouldn't take developers long to polish".
Smart PMs - "I made an unmaintainable, un-extensible proof of concept (at best) which cannot (and should not) be used as the basis for the real thing. But if(f) it's a better medium for software specifications/requirements than traditional written/visual specs, then it may add some value. The software development process hasn't otherwise changed a whole lot."
Also worth noting that in some ways, a working prototype could be worse than verbal/visual specs, since making the interactivity/clickyness could make it look like it's demonstrating a whole lot, whereas all the tricky little details a dev needs to make the real thing are missing or unspecified.
I wouldn't be scared because in practice we don't see this! Instead we see 1. devs appreciating getting an interactive mockup and 2. the PM having a better sense of what it's like to build technically. (It's pretty cool seeing how AI tools like Magic Patterns help non-technical software professionals naturally learn more about web dev concepts because the best prompts reference code.)
At big companies, Magic Patterns designs are used created & used at the beginning of the product lifecycle for brainstorming and iteration. And there's still a human in the loop in the process: the PM prompting Magic Patterns. The value we create is not the actual raw code, and so we are not seeing teams telling their devs to simply "polish" it. The handoff still is very similar to most dev/design handoffs today, except it's a Magic Patterns design versus a Figma design.
I mention this in another comment: v0 has been around as long as we have (October 2023), so it's very cool seeing how we have both iterated on the same problems, especially given Vercel is a $3B company and we are a team of two :-)
We have both evolved a lot and now have some major differences, given we focus on product teams more than developers:
- Magic Patterns has an infinite canvas
- Password protection on designs
- Feedback collection on prototypes
- Reusable components, so you can create a component library with us and then reference those components in your design
- We are only focused on frontend
A few customers actually use both us and v0! For example, they'll design in Magic Patterns and then copy paste the code into v0 to add a database.
I don't normally comment on these things, but I gave it a quick shot for a project I'm working on (fairly generic dashboard-style prompt, but that's fine).
I'm actually pretty impressed. A couple things though:
1. It took a _while_ to give me anything. Not sure if that's related to load, but it was ~17 files, and probably took 5+ minutes. It was not clear what was going on in that time, or what would happen if I left it. I literally left my machine to go something else before coming back.
2. I really hate saying this, but your pricing is probably way too low, especially at the "pro" level from your pricing page. When stepping into team-based config management and pre-sets, you're leaving a ton of money on the table without enterprise-style custom value-based pricing. If you were asking me, I would recommend moving the team based features (shared presets, custom access control, etc) into an "enterprise" level above pro).
I'm not going to comment on any sort of "correctness" as far as any complex UX behaviours or workflows; I'm only considering this from a mockup/design/demo-of-new-ideas perspective.
1. We're using Sonnet 3.7 for the first prompt. I've noticed with some prompts that require lots of files it can be PAINFULLY slow. Our servers also might be getting slammed from the HN traffic. We have a "fast" mode that uses 3.5 that you can toggle and that's the default for editing, however, it won't be as visually rich. We need to improve the loading experience for sure. One big UX/UI difference between our product and others is that our preview is always shown versus on other tools the code is always shown. Other tools will stream in the code to mask the load time. We used to do that, and will likely bring it back.
2. Re pricing - that's the most important feedback we'll hear all day! We used to have a "contact us for pricing" tier, but have found self-serve a lot more effective and easier to scale.
We actually still only 2 people, just my co-founder and me. When you say "custom value-based" are you referring to a "contact us for pricing" tier?
> When you say "custom value-based" are you referring to a "contact us for pricing" tier?
Ya. Not saying that it's applicable to everyone (or even most people), but really once a team gets above maybe 20+ people actively using this, they're not going to blink at $1200/month (good for you now, but you'll be leaving a ton of money on the table, and it's hard to adjust expectations later).
Maybe capping the size of a team on the "pro" plan would be an inbetween, but it's something to talk to your customers about.
Happy to chat more directly; my email's in my bio.
> Maybe capping the size of a team on the "pro" plan would be an inbetween
That's interesting. We already have teams with 20+ folks on it today at very large companies, but haven't thought about that type of stuff too much - have been laser-focused on core product building. I think in the early days we spent a little too much time tweaking minor pricing plan details. You're right though we are now at a point where we are very likely leaving money on the table.
For example, "centralized billing" on our platform only exists because it was the result of a feature request from a larger customer.
P.S. I emailed you, but it bounced!
Email you too; thanks for the heads on the bounce. Should be fixed now.
Don’t change your pricing model based off n=1 go do some market research first.
Don’t kill your adoption rates in the critical early days of growth.
We have been around for 2 years and at one point had "contact us for pricing", so don't worry not changing anything on n=1!
This is super cool—love how you’re flipping the AI-assisted creation story to focus on design-first workflows. The frontend-only scope is such a smart constraint, especially for PMs and non-designers trying to validate ideas fast without diving into fullstack territory.
I’ve seen firsthand how hard it can be for non-designers to clearly communicate product ideas, and Magic Patterns seems to lower that barrier in a really meaningful way.
I noticed the GitHub Sync option—curious how teams are using that today. Is it more of a dev handoff (e.g. PR previews) or a starting point for custom builds? Would love to hear how that fits into engineering workflows—especially for folks skipping Figma entirely.
Also really appreciate the collaborative angle. Real-time team prototyping on a canvas feels like the future of internal product reviews.
Rooting for you both—this is such a focused and thoughtful approach to a real gap in the market.
The Github sync is used by solo entrepreneurs or hobbyists to get what they've designed in Magic Patterns into their IDE. 99% of the time that's an AI-IDE, like Cursor. And then from their they might add backend functionality. It's pretty interesting seeing how Cursor is the "next step" after these types of tools for that persona.
On the other hand, for product teams with mature engineering workflows, it usually goes like this: 1. Designers/PM brainstorms an idea in Magic Patterns 2. They get feedback in a design crit or from their users by sharing the Magic Patterns URL. 3. They iterate on it further and then either export it to figma or hand it off to engineering directly. But! engineering won't use the code because we output React + Tailwind CSS, and they are very likely using custom components or have their own nuances.
I do think as the foundational models get better the dev/design handoff will get smoother, but I don't think we are there yet, especially for existing code bases. For new projects, it's a different story and our two-way Github sync plays a role.
> engineering won't use the code because we output React + Tailwind CSS, and they are very likely using custom components or have their own nuances.
That's what I think you could attack - in four ways:
- have a way for designers and developers to iterate components in a component library
- have a way for that component library to be used in app designs
- have a way to upload my component library and use its components in app designs
- eventually maybe extend the above to be able to use multiple component libraries (e.g. for companies with multiple brands)
I used magic patterns for a couple of months and it was one of the first no brainer AI services I've paid for outside of the main LLMs and IDEs. It did such an amazing job on quite an esoteric frontend that's very much not your normal web app. Impressive. Next time I need to design and build some more frontend code I'll be subscribing again.
Edit: to add some meat to that comment what surprised me was just how much better it was than Anthropic and OpenAI tools at that time for coming up with great looking products with minimal prompting. I also fed it other designs for inspiration and it replicated them brilliantly while incorporating my requirements. Good stuff.
Good to hear from you and see you on here!
Hi, Thank you for sharing.
I tried this prompt.
``` create a Rubik's cube app with all available moves and show the cube and the animations. add a scrambler and a solver. Also add timer to time the moves. ```
I got this.
https://www.magicpatterns.com/c/psesccrmk41jibfhwp7wh1
Which looks like a good starting point but doesn't work at all. After this it is daunting to look at code. I still have to figure out how to tell the chatbox to fix it.
Gemini 2.5 pro did much better in one shot. (the prompt was different and without the scrambler/solver/timer)
https://sumitkumar.github.io/llmgenerated-static/
Do you have the prompt you used for Gemini 2.5 pro? I think it would be interesting comparing prompt for prompt!
In this case, it looks like the Gemini output that you linked — as you mentioned — doesn't include the requirement for a scrambler/solver/timer, so it's hard for me to comment directly on the comparison.
I ask because we can totally add Gemini 2.5 pro as one of the models we use under the hood!
Here is the conversation link with gemini. https://g.co/gemini/share/d253e2ef286c
Well, I was not comparing but it was just an observation.
I understand Magic has more constraints on which libraries it can use and probably is for forms-flow kind of workflows and not for managing complex states of games.
That's pretty cool! Thanks for sharing. I like how Gemini used pure HTML/CSS to start.
While we certainly do constraint it, it still should be able to manage creating a Rubik cube solver (even though that is definitely not the intended use case).
There's a lot of "AI tourism" in the space and so never want to constraint it too much + random use cases like this always excite us: https://news.ycombinator.com/item?id=43752176#43752637
I created a basic flight simulator a while back in Magic Patterns in 3 prompts: https://www.magicpatterns.com/c/xensje9nkf48syshrkcmsc
Your Rubik's cube prompt I'm going to add to our eval set :)
I’m constantly intrigued how people are getting funding for entire companies that are essentially going to be a feature of all LLMs pretty soon.
There's a lot of work around UX and how you interact with the LLM. For example, given an entire React app + a user prompt to update it, which code snippet do you feed to the LLM? The LLM cannot read your mind. In a way it feels like the application layer's job to help it read your mind.
You probably know this, but just want to say, founder to founder: don't listen to this argument at all.
People are so fond of saying "just wait and the new model will do this." And very smart people I know say it (especially when they work for OpenAI or Anthropic!).
It might be partly true (of course it's situational). But it's a glib and irrelevant thing to say. Model capabilities do not advance like some continuous exponential across all domains and skills. Not even close.
Product design is exploring the solution to human problems in a way that you can bundle and sell. Novel solutions to human problems tend to come from humans, applying effort over time (with the help of models of course) to understand the problem and separate out what's essential and what's irrelevant to the solution.
(A related comment on the adjacent thread.)
I love what you wrote in the other thread too:
> "The hard part of being an engineer is not writing JavaScript. It is building a solution that addresses the essential complexity of a problem without adding accidental complexity."
I have been oversimplifying it as "LLMs cannot read you mind."
Do you not think that’ll get solved by a future generation of cleverer LLMs though? As someone pointed out in another comment, they get better results with Gemini 2.5 already.
People already seem quite annoyed with Cursor based on that thread the other day with the hallucinated customer support.
Interested in anyone’s opinion
> Interested in anyone’s opinion
Okay, I'll bite. My issue w/ statements like "building something an LLM will do in the future" is a constant goal-post moving argument.
It seems to equate to "how is this getting funded when AGI is going to do it eventually anyways". That applies to literally everything. "Why bother building a social media platform, soon an LLM will be able to build an entire one in a day!", "Why bother becoming a plumber, soon an LLM will be able to control manufacturing equipment to build a robot that can do it better than any human", "Who needs architects, LLMs will soon be able to design perfect buildings for whatever use case!".
If your point is only that some companies are currently getting funded that are a weekend-project away from getting Apple-d out of existence, then I would definitely agree that some companies are like that (just like some app companies were like that 6 years ago). Some companies are just super basic wrappers around someone else's LLM, but the expectation (from investors, at least) is that there's a bigger goal and the "easy weekend project" approach is for validation and building some sort of user base now.
However, I also disagree that this is the case here. Building good UX's around LLM usage is not just "using LLMs", and figuring out the use cases people actually want is also not just "using LLMs".
100% agree. There is a bigger point too: People assume LLM capabilities are like FLOPs or something, as if they are a single number.
In reality, building products is an exploration of a complex state space of _human_ needs and possible solutions. This complexity doesn't go away. The hard part of being an engineer is not writing JavaScript. It is building a solution that addresses the essential complexity of a problem without adding accidental complexity.
The reason this is relevant is that it's just the same for LLMs! They are tripped up just like human engineers into adding accidental complexity when they don't understand the problem well enough and then they don't solve the real problem. So saying "just wait, LLMs will do that in the future" is not much different than saying "just wait, some smarter human engineer might come along and solve that problem better than you". It's possibly true, possibly false. And certainly not helpful.
If you work on a problem over time, sometimes you'll do much better than smarter person who has the wrong tools or doesn't understand the problem. And that's no different for LLMs.
> Do you not think that’ll get solved by a future generation of cleverer LLMs though?
I don't. But obviously I'm biased + have spent perhaps too much time at application layer. I think there will still be a large amount of tooling + feeding of context to get the best result and I don't see a world in which we let LLMs run hog wild on our computers any time soon, especially for prototyping workflows at the enterprise level.
And for the sake of discussion: let's say these cleverer, future generation LLMs do exist... then I think the entire workflow will be very different. Hard to say how. Perhaps knowledge work as we know it will be unrecognizable.
Re: the Gemini 2.5 comment, I would love to compare it prompt for prompt. Looks like the prompt they are comparing it to didn't include the requirements for the Rubik's cubes scrambler/timer/solver. That said, I wouldn't be surprised if one LLM — Gemini 2.5 in this case — is better at creating a Rubik's cube compared to Sonnet 3.7/3.5 with our system prompt. (Not a lot of product teams are prompting our platform to build Rubik's cube in three.js lol). But if it is better, what's great is we can easily swap it out and start using Gemini.
Cool. Thanks for the insight. Good luck with it all! It seems like lots of people DO see the value in it!
Claude Code?
The value is in the application, not the model.
Model providers will be fungible. Applications will capture all the complicated interaction patterns, domain expertise, and distribution.
Apps can route between cheapest/most effective model. And the Chinese and upstart labs will continue dumping open source on the market. To get distribution, to salt the earth, commodify the compliment, etc.
When will an LLM be able to author a directory of GLB files organized into a game, precisely positioned within a world, with a set of user-tweaked PBR textures? Never. And even if it could, could you fathom the pain? The app layer will do that.
2025 is the year of the "App Layer" in AI.
If the company can build a big user base first, then they become a possible acquisition target in the future by the LLM company for their distribution, ala Windsurf selling itself to OpenAI.
How did you manage to advertise or generate initial traffic for something like that?
Even if the tool is excellent, it seems like the space is flooded with “Prototype your app with AI” tools, many backed by big players with huge ad budgets. The target audience must be getting bombarded with a dozen similar pitches every day. How did you manage to cut through the noise?
I find myself asking this question often, so there’s probably something fundamental I don’t quite grasp about startups in general.
> How did you manage to cut through the noise?
In startup land, I think it's really important you love your customer. Because you cut through the noise by having your existing customers tell their friends about you. 30% of new users hear about us from their friends.
I'll also note: we launched for the first time in October 2023. At the time the space was not flooded. We first got 10 users who loved us — where I define "love" as using us weekly — and since then it's a game of continuous iteration!
This is a very good idea. I see a lot of friction (and lack of process) with product -> UX -> dev than with product and dev able to iterate on things like screen flows very quickly, and UX feeding in more from the user research angle.
Currently a lot of UX work is "translate what you said into Figma and wait for comments" which is very automatable, and I think frustrating for UX people as much as anyone.
100%. This is what we hear and see from our customers, many now skipping Figma entirely.
I shared this post before below, but to share it again: https://www.linkedin.com/posts/stephenwitmer_you-gotta-love-...
I just had a cool experience with it doing some simple design. It prompted back to me usefully as well.
I can imagine also uploading a component library that this thing then uses the components from, to add styling for higher-fidelity designs, and allow app designers/builders to just use the components built by an internal team (who might also use magic patterns, I suppose).
Interesting. So, if you're targeting the PM and only building a frontend, are you actually competing with Figma? With the many use case of creating/iterating a UX prototype?
In which case - you mention that MagicPatterns creates components, but can it also reuse existing components? E.g. sometimes I'd want to create a UX prototype, but use a pre-existing UI / design language to match how my sites/apps are already implemented.
While we target the PM, it's a healthy mix of personas. We have many founders and designers who use us as well.
Some of the designers are indeed now skipping Figma, a direct quote from one of them (https://www.linkedin.com/posts/stephenwitmer_you-gotta-love-...):
> "I spend 80-90% less time drawing boxes in Figma - and more time using my insights, creativity, and words to create working prototypes [...] - to shorten feedback loops & better communicate vision."
Other designers will use us purely for brainstorming and then use the Magic Patterns Figma Plugin to export. The way this works behind the scenes is we convert the HTML to Figma nodes (https://www.magicpatterns.com/docs/documentation/get-started...)
We are rolling out a reusable components feature. If you hit us up in our support chat or email me: alex [at] magicpatterns.com I can add you to the feature flag!
Not using Magic Patterns but absolutely +1 this workflow. I'm a designer working across multiple teams and it's so fast and fluid to get react prototypes out of an LLM. I put together a vite project to drop the resulting typescript files into. Much quicker iteration with PMs and then we capture spec from the prototype. I see this as a way to scale our design efforts across the org since we can get higher resolution iteration done faster.
which tools are you using? And if you do end up trying us, let me know what you'd like to see or if we can help with anything!
It is remarkable how fast pure prompting can get you an interactive prototype.
We recently added the ability for our system to reference markdown files, so one thing you can do is paste a PRD into Magic Patterns and then tell it to reference that PRD as it builds out your spec.
I started out copying and pasting from Claude Pro. Then I hooked up MCP so it could edit files directly in my local repo.
I set up this template with all the shadcn components pre-installed so you can prompt something like, "make a prototype of this mockup using shadcn" and then just drop the page in without any extra importing or routing. https://github.com/pglevy/vibe-coding-boilerplate
We recently got Gemini at work so trying to use that now since everyone has access.
Single prompt, "A dating app for dogs"
https://project-dog-dating-app-454.magicpatterns.app/
Love it. Really impressed with how it pulls in meaningfully related stock images by default; v0 and the rest aren't doing that.
Love this one! Thanks for sharing!
Lol at: > You and Max have liked each other!
Yay! I like Magic Patterns. It is more useful and accurate compared other tools. I have successfully been able to get some design ideas implemented in it. It seems to understand consistency more than other tools.
I made a part of this using your tool : https://www.heated.studio/
Congratulations on the launch
Nice of you to comment! Website looks awesome.
In the earliest days of the product, we were hyper-focused on custom component libraries. We connected to Github repos and then fetched the relevant components for every prompt. We no longer do that because the models got a lot better and most customers don't care about the code, they care about the visual output. But this lead to us always caring a lot about consistency. Still iterating on that every day.
There were some comments on pricing that I'd like to comment on: As a one man startup that's fully self-funded I deeply appreciate the prices that aren't straight out of Sillicon Valley. I believe in free market and really don't mind companies doing profit first, but those are often services that simply are out of reach for the more budget conscious of us while adopting new technologies. Let me thus petition for keeping a small enterprise plan in the price range you're now at, maybe limited by nr of employees, company age, and/or even easier, the number of subscription months/years. That'll give us a chance to adopt your service while increasing the value we get from the service.. When the value's there I won't hesitate to pay a higher price for it either.
> or even easier, the number of subscription months/years.
We do offer 20% off on annual plans! ;)
We're very proud to be largely self-serve and have pricing that is completely transparent right now. Of course, we're open to feedback on pricing, especially enterprise pricing, which is why I was intrigued by the other comment.
And I agree, I think most people forget that a push back on price is really a push back on value, and so the value needs to be there first.
Canvas is an interesting idea - although the implementation feels very clunky and half finished.
rest of the tool doesn't feel that special - eg there's tonnes of code generators out there. would have to play more to understand but it wasn't immediately apparent
We always iterating and definitely need to improve! Anything you can point to explicitly that makes the canvas feel clunky/half finished? We're using a simple div under the hood!
To add some color: while we do generate code, we don't view ourselves as a code generator because our customers don't get value out of our tool from the raw code. They instead receive value from the interactive prototype, and for that reason it's lot of PMs, designers, founders using us versus developers.
Lack of tools (shapes, cards etc)
Also felt very laggy/buggy when selecting, dragging etc. may be my underpowered rig
Also just how separate the tool was - it was the primary reason I checked out the product but felt I had to go searching to find it.
Maybe a add to canvas/project button in the code gen area.
I gave it a shot to iterate on our current UI. It did try to solve the problem we were focused on, but it also randomly removed other features that we hadn’t touched or even talked about. This makes me believe there will be a lot of back and forth that is low value just correcting small details. In UX/UI details really matter. I'd probably opt to just move pixels around my self in this case.
If this were a brand new project with no existing UI at all and we just needed to spin up a quick prototype, I think it’d be great for that. And honestly, I do think LLMs will end up playing a big role in UX design over time—so this is definitely in the right direction.
But for real-world use cases where the UI already exists and quality or timesaving matter, it doesn’t feel like the right fit yet.
Our largest customers generally use us to prototype brand new UIs versus existing ones, so you're spot on.
We're certainly better at new UIs versus existing UIs. Existing UIs are tough because you need to first recreate what you have in the codebase first. This is a large reason why we built a Figma-like canvas (https://www.magicpatterns.com/docs/documentation/projects/ge...), so that you can reference existing designs to make new ones.
So, for example, you could make your navbar, button, dashboard, and then click on that and reference it to make another design.
P.S. if you're open to it, open a support chat or DM me? Would love to help you get more value and see what prompts are causing it to remove stuff. It can also be really frustrating when it removes features — what can be helpful is going back a version or also editing the code by hand. We've had code edit since day 1. Totally aligned everything needs to be a prompt to get the small details right.
i recently used Magic Patterns for a very niche use case and had a great experience:
i wanted to do show new customers examples of how they can use my product, which lives primarily in email.
to do it via Loom I would need to create tons of fake email addresses and juggle a whole complicated set of scenerios. and to do it in after effects would take forever.
so i used magic patterns to make an app that lets me upload JSON scripts of the email threads, and it animates them. if you skip to ~1 min mark on this video you can see the output https://drive.google.com/file/d/1iWC5U2Q3x30I5m1bTuN9c2OnfDo...
that's kind of you to share here!
Yes, it's incredible seeing what you can do with pure code. I think that's a lot of the magic here: with code, you can do anything. This part is super gratifying to work on.
From day 1, we have thought of code as a first-class citizen in Magic Patterns because that's all the LLM sees. So then at the application layer, it becomes our job to best help the user interact the LLM a.k.a feed it the most relevant code. This part is suuuuuper challenging.
Hey, your demo is great! (Neat use of Magic Patterns). Curious, do you provide outlook functionality?
So how are you different?
The biggest difference is that we only do frontend, and that's very intentional. There's no database provisioning, no integration with an auth provider.
At first this may sound like a disadvantage, but it helps us stay very focused on actual product teams and their workflows.
Examples include: 1. we have an infinite, real-time canvas for collaborating, 2. reusable components and leveraging your existing brand, 3. export to Figma, 4. password protection on designs, 5. feedback collection. These are all features that customers have asked for; we haven't found that product teams need to spin up a database or leverage a Stripe integration.
Last note: this space is absolutely massive and we find all the other tools popping up very motivating. We first launched in October 2023 (before most other tools) when all you could generate with GPT 3.5 was a small React component. Our long-term vision is to be the one-stop shop for frontend.
It looks neat, but it has to be asked. There's Lovable, Bolt, v0, etc.
other Magic Patterns co-founder here —
to add on to Alex's answer above, we also differ in that we have a lot of features focused around brainstorming / exploring ideas, versus just spinning up a fullstack app. For example, we have a "Commands" feature that lets you get four variations (that are guaranteed to be different!) of a prompt.
We also have a Chrome extension that lets you import designs from your existing product to ideate on top of existing content.
different from _____?
All of the other products in this space.
Other tools are AMAZING for spinning up actual fullstack apps and use cases that require persistent storage. But actual product teams aren’t asking for that.
Also, our customers tell us that anecdotally it feels like we error less compared to other tools because we are focused entirely on frontend (there’s less room for error). Of course, we still error a lot - not easy when natural language is your input set!! - but it helps to stay focused and theres less dependencies on a backend & database.
p.s. one of my personal favorite parts of Magic Patterns is that you can very easily revert to a previous version, which is possible because no backend or database!
I love the idea. I just tried it for the office software suite I'm building and although I wouldn't copy-and-paste the design it suggested, it gave me a few ideas to iterate on, and that's already useful. I'll explore it further when it's time for more design thinking (I'm pretty set on my current design for now)
Interestingly, part of the value of the project I'm working on comes from bundling an AI assistant so that you can get documents (spreadsheets, presentations, documents) from natural language, so there's some overlap--the obvious difference being I'm trying to build complex documents instead of complex UI
Awesome to hear — our goal is to get to a point where you can copy/paste the design, but we totally recognize that it doesn't always get you to a full high fidelity mock up with the current limitations. So the main use case we've seen a lot of success with is ideating and validating different branches, quickly.
Oh that sounds very neat — definitely similar in nature! Documents and UI are both complex and can require a lot of iterations to get right
FWIW I think it could get a pretty high fidelity mockup if I had spent more time with it! It was remarkably good for a single one-shot prompt which probably had 15 words or less. I'll definitely come back for more when the time is right.
Definitely — we've seen some pretty crazy high fidelity mock ups from our customers who spend hours and hours prompting away, and they genuinely blow my mind. it's honestly why we spend so much time working on the application layer (e.g. making it easier to feed context into your prompt, referencing other designs, etc) since we know that the LLM is capable of these things, it just takes much more time than most people are willing to put in.
would love to hear what you think when you give it another try!
Played around with it, really nice, will definitely use it in the future!
thanks for commenting! Anything we could be doing better or initial thoughts?
To be honest I was up and running in less than a minute so nothing stands out. I didn't dive deeper right now but if I could do this and export to Figma directly that would be 100% of my use cases right now.
Well the good news is you can export to Figma! https://www.magicpatterns.com/docs/documentation/get-started...
Feel free to DM me if anything else comes to mind, can even hop on a Zoom too. Appreciate the response.
Hey kids, grizzled UI designer and developer at a startup here. You’ve got 2 keys correct right at the start.
1. Permissions/auth for prototypes. Stakeholders go for that. MBA folks don’t want to be sent crazy random obfuscated URLs, they want a nice login page that makes them feel secure. (Because MBA types will get weird about corporate secrets, even just high-level wireframes.)
2. Figma/Miro-esque infinite canvas with comments. Product managers and stakeholders love that flow.
Two features that are the direct result of customer feedback and consistent product iteration!
congrats on the launch! I gave it a spin.. found these issues:
1 - after selecting the Body of this page to capture as Design: https://app.visualsitemaps.com/pricing the "Render" tab > result showed be a blank box: https://share.cleanshot.com/jVGlwYND yet there was code in the "Code" tab.
after that it attempted to recreate the design, with some new additions:
- add a row of logos ( failed ) - add testimonials - add case studies - remove a row
Results >> it was 92% there: https://project-tailwind-conversion-with-lucide-icons-756.ma... had some missing images from the OG design.
Overall this is impressive for MVP.. I also like the manual click-to-select-objects for more refinement.
I was unable to find the CSS styling code however ( sorry not a React/Tailwind user ) it just showed me index.css like so: {@import 'tailwindcss/base'; @import 'tailwindcss/components'; @import 'tailwindcss/utilities';}
If it's helpful, the styling will be in the "jsx" file vs the css file! So when you use that "manual click-to-select-objects" feature in the chat bar, you can click on "Highlight Code" and then that will take you to the React component. In that component, you'll see a className field which will have Tailwind classes in it. That's technically what is applying the styling and boiling down to raw CSS.
Ah! Need to clean up what's happening there when using the Chrome extension to import an existing design - pushing up a fix. There's a great discussion on the extension here (https://news.ycombinator.com/item?id=42043552) btw if you're curious how it works.
When it comes to adding images, it works best if you give it an existing image URL or upload an image, which we then host for you. In this case, Sonnet 3.5 appears to have hallucinated an invalid image link. Also need to make this more robust!
hmm having an "Edit Style" for any object, in 1-click ( instead of traversing into component's guts, etc ) will be a more frictionless UX. in fact just show the same Figma Style UI controllers would be even better since that is a proven UX mental model;-)
that's great feedback, thanks!
I'm interested in understanding your desire to do design and prototyping as a single shot?
My expectation was that I'd iterate on a few UX designs with the LLM and then when I'm happy with what the LLM is suggesting, I'd output to figma, and then maybe move to code.
It's great that you're generating code, but isn't that increasing your cost and processing time to write code for each iteration?
What do you mean by "single shot?" Are you referring to one-shot prompting? I should have clarified in my post — we do have customers who one-shot designs - but that's very rare (it's usually landing pages because Sonnet 3.7 is really good at those). We heavily encourage iteration and expect it. The longest thread on the platform is 850+ messages in a single chat!
We have a fine-tuned fast apply model for applying code diffs, so that helps minimize the processing time. Always trying to make it faster though.
We view code as a way to 1) unlock interactivity, 2) communicate with the LLM.
A question for you: if we weren't asking the LLM to generate code, what would we ask it to generate?
I was thinking the process would be
1) as for a certain UX design 2) AI shows me an image of what it thinks I want 3) I make suggestions, changes to what I want 4) AI makes changes, shows me an image 5) back to step 3 and repeat until I'm ready to view code 6) have the AI write the code of the UX once.
I understand this may mean there are multiple images showing a flow, or different states, but in my mind, the time consuming part is the AI creating each JS file for the UX. I would think it could iterate quicker on designs and then output code.
This is how UX is designed today, designer does a bunch of iterations, gets feedback, then hands it to developer.
Right now, you're doing this all at once (or at least that is what my experience was).
I get what you mean about code as a method of communicating with the LLM, and I'm an engineer, so I kinda get that, but my first reaction wasn't "let's look at the code output", I was looking at the design output and thinking "is this what I want?"
I don't think generating images would be faster than generating code, plus you lose all the interactivity. Many designers tell us where they get the most value out of Magic Patterns is that the designs are interactive by default, unlike traditional vector-based design tools.
I'm with you that the first reaction is not "let's look at code output." In fact, for most of our users, they never look at the code. It's abstracted away from them and just an implementation detail to unlock interactivity.
P.S. You might enjoy our /Inspiration command, which gives you 4 variations at once. Demo video: https://www.magicpatterns.com/docs/documentation/editor/edit...
Appreciate the HN guest login. That's a good idea :)
hey thanks! spun that up over the weekend. I noticed another Launch HN did that and thought it was brilliant. we are here for feedback, so wanted to make trying it as easy as possible!
I can't find the "Coming from Hackernews?" button. Where should I look for it?
On https://www.magicpatterns.com/ you should see an input box. Type anything you want, hit enter, and then you'll get hit with our regular login panel. But at the bottom, for today online, you'll see a "Coming from Hackernews, no login required" button.
Tried it, it's very impressive. A perfect start prior to a new Windsurf/Cursor project.
This seems like the death knell for theme stores.
I'm CTO at a startup and Magic Patterns is amazing, my current workflow is to ideate using MP then implement straight to my codebase.
The instant feedback-loop of iterating over components is great and perfect for me when I'm designing a feature that's heavy on the client side of things.
For example it took me half a day to go from idea -> design -> implementation
That's largely how we use it internally too. I often use Magic Patterns first to think through the steps and user interactions, and then I'll jump into cursor to start implementing.
p.s. great to see a customer on here. appreciate it.
This is something I would definitely use, as my company pays for v0 today for these exact purposes (product design/PM).
I've tried some of the same prompts I've done on v0 but didn't notice a lot of difference -- needs a lot of back-and-forth, as with v0. So not sure what would make me switch at this point.
v0 is an amazing product. They've been around as long as we have (October 2023), and it's cool seeing how we have both iterated on the same problems.
Some differences with v0:
- Magic Patterns has a Figma-style canvas for collaborating with stakeholders. Makes it easy to view all your chats. - Password protection on designs (this is very important for some companies!) - Feedback collection on prototypes - Reusable components, so you can create a component library with us and then reference those components in your design. - We are only focused on frontend, which we think leads to less hallucinations. Also, when there is no database, you can go revert back to a different version of the design at any point.
We have a course for PMs, in case you find it helpful! https://www.magicpatterns.com/docs/documentation/ai-prototyp...
Why would you limit the tool to strictly be for React?
"As per my limitations, I am designed to work specifically with React and TypeScript/JavaScript only. I cannot provide direct conversions to plain HTML/CSS or other frameworks."
Mainly to narrow the problem space: there's a lot of logic in our backend that we call "post processing" which is cleaning up the code after the AI generated it to fix hallucinations. For example, the AI often gets import statements wrong or misspells icon names.
It's pretty interesting because every model seems to introduce a new set of hallucinations, so this is a problem that requires a lot of maintenance. We have this internal mantra to "use AI as little as possible" especially it's a problem that can be solved deterministically.
Also, because we are more focused on PMs, designers, and product leaders the code is largely an implementation detail. What they care about is being able to visually communicate their ideas, and React just happens to be a great way to do that because LLMs are great are outputting it + we have a pipeline to render it. (We are React developers ourselves.)
I'm curious, if you have that philosophy (which makes a lot of sense), you must have considered building is a sort of more abstract (but extensible) UI toolkit language and library and you could code in that then compile it down to React? Or have you found the benefit of large LLMs already having detailed React training is just too high?
> have you found the benefit of large LLMs already having detailed React training is just too high?
This.
We've tried a lot. We have been around since Oct 2023. First tried fine-tuning, but it's very hard to teach an LLM something new.
At one point, our product lived in a Figma plugin (https://x.com/Teddarific/status/1729153723728011618). To do this, we had the LLM output JSON, and then converted that to Figma nodes. This is sort of what you're saying. But the big issue was it would hallucinate many things and was really only good at the examples we fed it.
I want something which looks like design for engineers. I'm a programmer, code completion is nice, but I already know how to code. What I am terrible at is design.
I think sometimes people think design is purely making things "look good", but I come to realize it's also making things "work good!" a.k.a making it intuitive. "Don't make people think!"
It's been pretty cool to see how a tool like Magic Patterns is helpful for software builders to think through the flow for whatever feature their building. This is largely how I use it internally. For example, when I added our deploy feature, I first used Magic Patterns to think through what steps I needed to add: https://www.magicpatterns.com/c/d9sb9eavgnpjv1d5vaw6wa
This is long way of saying that one way I have become a better designer is by using AI as a creative assistant, but then also recognizing when to not reinvent the wheel. You also want to leverage existing patterns as much as possible.
I uploaded a screenshot twice but it keeps saying "Sorry, I don't see a screenshot!"
oof! this is a bad bug that seemed to tick up overnight! Fixing this, thanks for flagging. If you create a support chat via "Get Support" or DM me happy to throw you some credits and regenerate it for you.
frontend only makes so much sense!!
what are the plans to support design systems? no one seems to be able to do this. prototyping doesn't happen in a vacuum, I'll always want to use the design system we spent months building in Figma.
Yes! We have a feature for reusing components where you can prompt "use my @design-library/button." But right now @design-library needs to be re-created in Magic Patterns. This is behind a feature flag, but let me know your account email or DM me alex [at] magicpatterns.com and we can add you to it!
We're looking into importing from Storybook too, but it can get fairly custom and we want to make sure it scales. It gets tricky because these systems are expecting a certain format - in our case React + Tailwind - and so if the design system isn't that, the LLM won't handle it well.
Video demo of recreating LinkedIn's design system: https://www.linkedin.com/posts/teddy-ni_i-created-a-custom-d...
Once you figure out how it can understand all my Figma components and their styles (maybe via some “design”MCP).. it will make me 100% switch my design proto workflow!
Curious what the advantages are over something like Replit?
I wrote answer to that here https://news.ycombinator.com/item?id=43752176#43757543 - let me know if I can answer anything specifically!
What I'll add is we are seeing customers use Magic Patterns + other 'vibe coding' tools in conjunction. For example, they might use Magic Patterns for brainstorming and to think through the design, and then they'll copy the code from Magic Patterns into Replit to "make it real" and add a database or authentication.
just letting you know one of the flying boxes had clipped through the text i was editing, hard to recreate it but happened randomly.
ah thanks for letting me know, that happened to me once too. will adjust the logic!
does Magic Patterns support exporting components directly into frameworks like Next.js or Tailwind CSS out of the box?
Yep! It's all React under the hood, and the default is Tailwind. You can also sync to Github directly.
cool, congrats on the launch!
This service is pretty much what I, a software developer, am scared off. I expect that it will be used in order to quickly cobble something together and then hand it over to a dev for "polishing". And this sounds like a total nightmare to me.
If used like that, this service will effectively turn my job into that of an assistant to a machine.
It will happen. Product managers will essentially vibe code and make a thing that mostly works before handing it to developers for 'polishing'.
This could go two ways:
Dumb PMs - "I did most it myself in a week, it shouldn't take developers long to polish".
Smart PMs - "I made an unmaintainable, un-extensible proof of concept (at best) which cannot (and should not) be used as the basis for the real thing. But if(f) it's a better medium for software specifications/requirements than traditional written/visual specs, then it may add some value. The software development process hasn't otherwise changed a whole lot."
Also worth noting that in some ways, a working prototype could be worse than verbal/visual specs, since making the interactivity/clickyness could make it look like it's demonstrating a whole lot, whereas all the tricky little details a dev needs to make the real thing are missing or unspecified.
I wouldn't be scared because in practice we don't see this! Instead we see 1. devs appreciating getting an interactive mockup and 2. the PM having a better sense of what it's like to build technically. (It's pretty cool seeing how AI tools like Magic Patterns help non-technical software professionals naturally learn more about web dev concepts because the best prompts reference code.)
At big companies, Magic Patterns designs are used created & used at the beginning of the product lifecycle for brainstorming and iteration. And there's still a human in the loop in the process: the PM prompting Magic Patterns. The value we create is not the actual raw code, and so we are not seeing teams telling their devs to simply "polish" it. The handoff still is very similar to most dev/design handoffs today, except it's a Magic Patterns design versus a Figma design.
> If used like that, this service will effectively turn my job into that of an assistant to a machine.
I think you can already reduce commercial roles to this description if you choose to.
What does this look so similar to v0 from Vercel?
I mention this in another comment: v0 has been around as long as we have (October 2023), so it's very cool seeing how we have both iterated on the same problems, especially given Vercel is a $3B company and we are a team of two :-)
We have both evolved a lot and now have some major differences, given we focus on product teams more than developers:
- Magic Patterns has an infinite canvas
- Password protection on designs
- Feedback collection on prototypes
- Reusable components, so you can create a component library with us and then reference those components in your design
- We are only focused on frontend
A few customers actually use both us and v0! For example, they'll design in Magic Patterns and then copy paste the code into v0 to add a database.
Y'all are doing amazing. Keep it up!
very cool!
[dead]