4 ms·
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
by alexdanilowicz 1y ago
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.
- robertlagrant 1y ago> 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)