3
11 Comments

I spent months building an open-source UI library alone, and I'm scared of shelving it like every other project I never finished

Hey everyone, first post here.

For the past few months I've been building Orea, a free, open-source library of animated React components (built with Framer Motion). It started because I kept getting frustrated with how AI coding tools generate frontends — same generic template every time, and the moment you ask for something specific (a custom animation, proper color handling inside a card) it falls apart in unexpected ways.

So I built two things:

1. 37+ animated components you can install via npm or copy-paste straight into your project (similar approach to shadcn/ui, but pre-animated)

2. An AI "skill" you can hand to tools like Claude or Cursor so they generate visually consistent UI instead of guessing

It's not meant to replace shadcn or your component library — it's more of an animation layer that works alongside whatever you're already using.

I'm a solo founder, this has been a side project, self-funded, no revenue model right now — just wanted to build something useful and open-source it.

Honestly, the hard part isn't the code. I have a history of building things and letting them quietly die because I never got feedback and lost momentum. I don't want that to happen to this one.

So if you have 5 minutes: take a look, break something, tell me what's ugly, tell me what's missing. Tested on Chrome/Edge, desktop and Android — if it looks broken on your setup, tell me your device/browser and I'll fix it.

orea.ink

Appreciate any feedback, even the harsh kind.

posted toAvatar for product Orea
Orea
  1. 1

    The line that matters in your whole post isn't about the components — it's "I have a history of building things and letting them quietly die because I never got feedback and lost momentum."

    I've got four of those. What I finally learned is that they didn't die from lack of feedback — they died because I built them for "developers" in general, which is the same as building for no one. Feedback keeps you warm for a week; it doesn't keep a project alive. What does is 5 specific people who'd be genuinely annoyed if it vanished. So the antidote to quiet death isn't more eyeballs on the library — it's finding the handful whose pain (AI generates ugly frontends) is acute enough that they keep reaching for it.

    And one concrete piece, since you asked for harsh: an animated component library lives or dies on prefers-reduced-motion. Accessibility is the corner I work in, and it's exactly what shadcn-adjacent libs half-do. If every Orea component respects reduced-motion properly out of the box, that's not a checkbox — it's a wedge, because it's the one thing the AI tools you're competing with never get right. Nail a11y on animation and you've got a reason to exist that's hard to copy.

    Rooting for this one staying alive.

    1. 1

      This was a new point, I had no idea how important it was. Thank you for your great feedback💜

      1. 1

        Glad it landed. One follow-on so it actually sticks: don't put it behind a prop people have to remember — read prefers-reduced-motion at the CSS layer (@media query) so it just works the moment someone drops the component in. The whole value is that it's default-on; a prop defeats the point.

        If it helps, ship one component that way, put a two-line note in the README ("respects reduced-motion out of the box"), and lead with that. It'll pull the right people in harder than ten more components will.

        Rooting for Orea. Ping me if you want a second pair of eyes on the a11y side — it's the corner I work in.

  2. 1

    Your shelving pattern makes sense - most open-source projects die when the feedback loop breaks. But here's the thing: feedback isn't passive. The projects that survive aren't waiting for downloads - they're actively pulling people into the momentum.

    Right now your ask is "break something, tell me what's ugly" - but that requires someone to already care. What if you inverted it: find the 5 existing projects/communities that build frontends for AI tools (prompt builders, AI dashboard templates, coding assistants) and reach out directly with "I built this for your exact pain point, here's how it saves you 10 minutes on the next component you ship."

    When one of them actually integrates it and posts about it, that PR/issue Aryan asked about becomes inevitable. The retention killer isn't low adoption - it's being alone with your code. Get 3-5 people shipping with it before the first month ends, and the momentum sustains itself.

    1. 1

      I really liked your idea, and I had never thought of it from this angle before.

  3. 1

    "Help AI tools stop generating" is a developer pain point, but there are two developers here. The indie dev building a chatbot wants a free loading state component from GitHub. The enterprise team building an AI dashboard wants a polished design system with Figma files, theming, and support. Your $0/mo and React component framing attracts the first and makes the second think "this is an indie side project, not a design system we can standardize on.

    1. 1

      That's a very valid point, and to be honest you're right - I haven't chosen a specific path yet.

      Right now, Orea is built for the first developer you described: the indie/solo developer who wants a beautiful, free component without the need for refactoring. That's me, and that's what I thought of first.

      The initial design of an enterprise design system (Figma files, templating, support) is a real market, but it's not today - and I'd rather be honest about that than minimize the situation and serve neither well. If Orea grows and there's real traction from teams that want it, I'd rather intentionally build it later than pretend now.

      Thanks for naming this so clearly - that's exactly what's hard to see from the inside.

      1. 1

        The indie dev who wants a free loading spinner for their side project has zero willingness to pay and will fork your GitHub repo without a thank you. The indie dev who is building a paid product and needs their UI to look $10K professional will pay $49 for a premium component kit — but only if it saves them from hiring a designer.

        The risk: your free, no-refactoring positioning attracts the first and trains the second to think "this is a charity project, not a product I can rely on for my launch." If you want to stay indie, that's fine — but make sure you're attracting the indie dev who is shipping to customers, not the one collecting side projects.

        I run PreLaunch AI — we simulate exactly this: which indie dev segment converts to paid and which one stays free forever. Happy to model your indie dev split if you want to see where the $49 buyer is hiding. No strings — you already did the hard part by picking a lane.

  4. 1

    You mentioned shelving past projects after the feedback stopped coming.

    What would have to happen with Orea over the next few months for you to decide it deserves to keep getting your time — installs, repeat users, contributors, or something else?

    1. 1

      Honestly, for me success isn't a specific number — it's whether the problem I personally ran into and solved actually gets used by other people. I rely on free, open-source tools every day myself, so being able to give something back to that same community and contribute even a small part to it is what would make this worth continuing.

      That said, if I'm being concrete: a handful of people actually using it in real projects, or someone opening an issue/PR because they cared enough to improve it, would tell me it's landing.

      1. 1

        I appreciate you explaining that. The distinction between growth as a number and evidence that someone cared enough to actually depend on or contribute to the project is interesting.

        I'd be interested in continuing the conversation by email if you're open to it. What's the best email to reach you on?