[HN Gopher] Launch HN: Magic Patterns (YC W23) - AI Design and P...
       ___________________________________________________________________
        
       Launch HN: Magic Patterns (YC W23) - AI Design and Prototyping for
       Product Teams
        
       Alex and Teddy here. We're launching Magic Patterns
       (https://www.magicpatterns.com), an AI prototyping tool that helps
       PMs and designers create functional, interactive designs and
       websites. There's a demo video at
       https://www.youtube.com/watch?v=SK8C_tQBwIU, as well as video
       walkthroughs of specific examples at
       https://www.magicpatterns.com/docs/documentation/tutorials/v...
       While other tools help with "AI-assisted coding," we have been
       quietly focused on "AI-assisted designing." With Magic Patterns you
       can visually communicate your idea, get hands on feedback from
       customers, and test new features.  Teddy and I are best friends and
       former frontend engineers turned founders. We arrived at Magic
       Patterns after several pivots--always in the design tooling space,
       but different products that all struggled to get usage. We started
       working on Magic Patterns after an internal hackathon. Teddy built
       a UI library catalog and I messed around with GPT 3.5. We thought
       it'd be fun to combine the two: an AI component generator. Describe
       whatever you want, and get back a React component!  That started to
       take off and we gained users, but it wasn't developers using the
       tool. Instead, it was PMs, designers, and leadership who could
       finally communicate their ideas. They use it to test new ideas
       quickly, get feedback from customers, and improve communication
       with internal teams. Also, hobbyists (and programmers who aren't
       designers) use us to create designs and UIs that they wouldn't be
       able to otherwise.  We use Sonnet 3.5 and 3.7, and leverage a fine-
       tuned model for fast-applying edits. The most challenging part is
       determining the most relevant context to feed to the LLM. We
       attempt to solve this with our click to update feature and by
       letting users define a brand preset, or default prompt.  Unlike
       other tools in this space, we're specifically focused on (1)
       product teams--we're realtime and collaborative; and (2) frontend
       only--we don't spin up a database or backend because we aren't
       solving "idea to fullstack app."  A common workflow is a product
       manager building an interactive prototype and then passing it off
       to a designer for more polish or directly to engineers. Many teams
       are even skipping Figma entirely now, telling us that it feels like
       an unnecessary middleman. Teams are instead generating clickable
       prototypes, collaborating directly with stakeholders, and using
       that as the mockup.  With Magic Patterns, you can: - Collaborate
       with your team on our infinite canvas; - Match your existing
       designs by creating reusable components directly; - Brainstorm
       features and flows. (The latter is what we use it for internally.)
       We started as a way to build small, custom components, but now
       people are one-shotting entire websites and hosting them with us,
       or building dashboards that they share internally or in customer
       demos. People have sold $10k/mo contracts with Magic Patterns
       designs!  Small business owners--everyone from fishermen to driving
       instructors to hotel managers--are using us to build their websites
       and then hosting them with us. Example sites built by Magic
       Patterns include https://getdealflow.ai/ and
       https://joinringo.com/. It's amazing how people who couldn't have
       done that before are now able to, and super gratifying to us to be
       empowering people in this way.  You can get started with our docs
       here: https://www.magicpatterns.com/docs/documentation/get-
       started..., and you can try the actual product. Simply go to
       https://www.magicpatterns.com and prompt for any UI you want.
       Today no login is required, just click "Coming from Hackernews?"
       and you'll get 5 messages free to try. Once you hit the limit,
       you'll then be prompted to login. Plans start at $19/mo for another
       100 messages a month (https://www.magicpatterns.com/pricing).
       We're stoked to be sharing with HN today and are open to all
       feedback!
        
       Author : alexdanilowicz
       Score  : 106 points
       Date   : 2025-04-21 14:07 UTC (8 hours ago)
        
       | sebastiennight wrote:
       | 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.
        
         | alexdanilowicz wrote:
         | 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!
        
           | pglevy wrote:
           | 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.
        
             | alexdanilowicz wrote:
             | 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.
        
       | dhruv3006 wrote:
       | So how are you different?
        
         | airstrike wrote:
         | different from _____?
        
           | lgas wrote:
           | All of the other products in this space.
        
             | teddarific wrote:
             | 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!
        
               | airstrike wrote:
               | 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
        
               | teddarific wrote:
               | 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
        
               | airstrike wrote:
               | 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.
        
               | teddarific wrote:
               | 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!
        
         | esafak wrote:
         | It looks neat, but it has to be asked. There's Lovable, Bolt,
         | v0, etc.
        
           | teddarific wrote:
           | 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.
        
         | alexdanilowicz wrote:
         | The biggest difference we only do frontend, and that's very
         | intentional. There's no database provisioning, no integration
         | with an auth provider.
         | 
         | At first this many 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 an 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.
        
       | getbreadbox wrote:
       | 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...
        
         | alexdanilowicz wrote:
         | 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.
        
         | financetechbro wrote:
         | Hey, your demo is great! (Neat use of Magic Patterns). Curious,
         | do you provide outlook functionality?
        
       | sutterbomb wrote:
       | Appreciate the HN guest login. That's a good idea :)
        
         | alexdanilowicz wrote:
         | 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!
        
       | ygreif wrote:
       | 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.
        
         | alexdanilowicz wrote:
         | 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.
        
       | shoemakerevan wrote:
       | 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.
        
         | alexdanilowicz wrote:
         | 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.
        
       | lnenad wrote:
       | Played around with it, really nice, will definitely use it in the
       | future!
        
         | alexdanilowicz wrote:
         | thanks for commenting! Anything we could be doing better or
         | initial thoughts?
        
           | lnenad wrote:
           | 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.
        
             | alexdanilowicz wrote:
             | 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.
        
       | pelagicdev wrote:
       | 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."
        
         | alexdanilowicz wrote:
         | 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.)
        
           | zalzal wrote:
           | 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?
        
             | alexdanilowicz wrote:
             | > 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.
        
       | kaywu wrote:
       | frontend only makes so much sense!!
        
       | sumitkumar wrote:
       | 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/
        
         | jonplackett wrote:
         | 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.
        
           | tibbar wrote:
           | 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.
        
           | alexdanilowicz wrote:
           | 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.
        
             | jonplackett wrote:
             | 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
        
               | alexdanilowicz wrote:
               | 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 now 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.
        
               | jonplackett wrote:
               | Cool. Thanks for the insight. Good luck with it all! It
               | seems like lots of people DO see the value in it!
        
             | throwaway7783 wrote:
             | Claude Code?
        
         | alexdanilowicz wrote:
         | 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!
        
           | sumitkumar wrote:
           | 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.
        
             | alexdanilowicz wrote:
             | 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
             | :)
        
       | jcgr wrote:
       | 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
        
         | alexdanilowicz wrote:
         | 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.
        
       | cpinto wrote:
       | 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.
        
         | alexdanilowicz wrote:
         | 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...
        
       | jiwidi wrote:
       | very cool!
        
       | mildlyhostileux wrote:
       | 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.
        
         | alexdanilowicz wrote:
         | 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/documenta
         | tion/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.
        
       | indiantinker wrote:
       | 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
        
         | alexdanilowicz wrote:
         | 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.
        
       | consumer451 wrote:
       | 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.
        
       | arturmakly wrote:
       | 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';}
        
         | alexdanilowicz wrote:
         | 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!
        
       | JofArnold wrote:
       | 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.
        
         | alexdanilowicz wrote:
         | Good to hear from you and see you on here!
        
       ___________________________________________________________________
       (page generated 2025-04-21 23:00 UTC)