Paramancer - Claude Code for Iterative 3D Modelling
Hey Indie Hackers,
I’ve been working on a project called Paramancer: think Claude Code, but for iterative 3D modeling.
Instead of opening Blender, Fusion, or OnShape and building a bracket or pegboard mount from scratch, the idea is to describe what you want in plain language and have an LLM generate a parametric 3D model you can iterate on.
You can then refine the design conversationally: adjust dimensions, add mounting holes, tweak tolerances, and regenerate until it’s right.
I’ve had some early success producing useful and interesting models, but the real challenge is scale. To get there, I’m building a feedback loop and dataset that captures how people describe parts, how models fail, and how they get corrected—so the system can steadily improve.
So far I’ve run ~100 different iterations by hand and built internal tooling to help refine and fine-tune the model, but I’d love to take this further with real users and real use cases.
I’m very early, but excited about where this could go. Would love feedback, criticism, and ideas from folks who design parts, print them, or just hate CAD UIs as much as I do.
Check us out at paramancer.app
This is interesting especially the focus on iteration rather than one-shot generation.
One question that feels pivotal early: who is the first user you’re optimizing the feedback loop for? A hobbyist printing brackets, or someone under time pressure (e.g. small hardware teams, ops folks fixing jigs)?
From what I’ve seen, conversational tools get sticky fastest when there’s a clear “done” definition (fits, prints, doesn’t fail) rather than open-ended creativity. Curious how you’re thinking about narrowing that first loop.
Great questions! Ideally both, but I was going to base it on the feedback of putting it out in the wild and seeing what others are interested in.
I'd love to see Paramancer become an industry standard; but keep a tool that works for the average maker or anyone with a 3D printer.
The tool comes down to the user base and the feedback that we can use to teach the engine so that we can refine the outputs to be intuitive to whatever the audience that the tools is being used.
That makes sense and the ambition to become a standard is the right long-term instinct.
The one thing I’d gently push on is this part: “put it out in the wild and see what others are interested in.” That works for feature discovery, but early on it can blur the feedback loop you’re trying to teach the engine with.
What I’ve seen work best with tools like this is:
You declare a primary loop first (even if it’s temporary)
You still accept everyone else’s feedback, but you weight it differently
For example, you might internally say:
“For the next X months, success = parts that fit and print on the first or second iteration for time-constrained users.”
That gives you:
A crisp “done” signal (fits / doesn’t fail)
Much tighter training data
Clear intuition about what the engine should optimize for (speed, tolerance sanity, fewer iterations)
Hobbyists will still benefit but users under time pressure tend to give higher-signal feedback because failure is costly to them.
Once that loop is rock-solid, expanding toward “industry standard” becomes much easier because you’re scaling a proven constraint, not a vague promise.
Have you thought about running the first version with a declared primary user, even if the door stays open to everyone else.
Claude Code for 3D is interesting, but 3D modelling is a tough market (Blender is free, professionals use industry,specific tools).
Have you validated who pays for this? Indie game devs, architects, or product designers? Each has different willingness to pay.
I built FounderOS to validate niche developer tools before building. Happy to check this 3D concept for you, see if the market supports it or if it's a feature not a product.
Drop the target user or DM me?