The compact answer is software complexity, intrinsically complex algorithms and geometric robustness. Data model may be difficult depending what you want to do. Robust import. Robust export domain to domain.

The last two are especially nasty if you are solo since there are no good specs here. There are _specs_ but what happens in practice is that each party has their own implementation that almost works, except in n. corner cases. Then you need to figure out is your software wrong, or is the input data wrong, and not rush to hasty conclusions. This will be time consuming.

Even though Claude's improved considerably in the past few months I'm super impressed what you achieved in a very little time.

You clearly know what you want and how to get there.

The key here is _you design parts_ for _your job_.

You _already_ know what the requirements are to do _your job_.

The HN critique is pointless noise honestly (sorry guys but that's how it usually is, queue 'Dropbox' critique). If you want to develop this further, design your robot with this, then find other people building robots, test can they use this and fix the parts that don't work for others, iterate.

What's your most important talent here? Not the software engineering bit. You are an industrial end user yourself. If you give me a room full of four mediocre software engineers and one person who understands the end user deeply, and a room with 1-2 kick-ass programmers 9/10 times the room with the domain expert wins. Now in this case you are the programmer and the end user. I'd say I would bet very high on good outcomes for this project if you can keep at it and can sustain empathy for end users (not all of them! just the ones you care about).

So rather than explain this as "CAD" explain it as "CAD for doing X" and I would hazard X in this case is robots.

I mean it's startups 101. You develop a tool to solve your own problem. Then you build your mvp and find your next users. You know how to build robots and what the problems are. I guarantee you 100% there are other people building robots, well capitalized, and they have exactly the same problems as you.

That said the problems to you may not be problems to others. Not all solution are universal. That's why understanding _the market_ needs with an mvp after you know how to solve your own problems is critical.

"I will solve your problem" and "this will exist in 10 years" are the two magic words to industrial adoption if you are not bullshitting and find someone to hustle those first magical beached users in.

If history of software business has taught us anything it's this: The _most important talent_ in developing complex software is not be a kick ass software engineer. It's to understand the end user. And in industrial workflows end user pain has an immediate and usually significant financial benefit to it which means if you actually can penetrate the market do plan for making this into a business. But not an open source one. Those end in tears usually. See Ondsel for example https://www.ondsel.com/blog/goodbye/. I don't know _why_ these things fail but I _guess_ there comes a point where you need to be well capitalized to make headway and capital does not seem to like open source. I'm not telling you what to do! I'm just giving a fair warning the Open Source route may be the more difficult one unless you land exactly right.

--

To answer you _technical_ question the 1st difficulty _is_ figuring out to whom the software is and what they do with it.

There is no "universal" CAD. _All_ of the applications are tailored for a more or less specific industrial design workflow. Mech eng is totally different than AEC which is totally different from circuit design.

The second hard part is understanding the software's position in the value chain. What are the inputs. What are the outputs.

Traditionally in CAD the final outputs have been a) drawings b) manufacturing robot control code (GCODE, CAM etc) c) documentation (database, drawings, 3d models... whatever the documentation spec requires)

And in addition to this there are the software that sit "in between" where the input is a design file from previous modeling step or software, and output is another design file.

Why are these hard? Markets are surprisingly opaque unless you participate in them - there is no playbook to copy, you have to mostly discover it yourself.

Now what does this have to do with _the actual part of modeling_?! Well, the user requirements drive the outputs _which drive the requirements_ to your surface model and the enrich data landscape where it lives.

Based on what I'm reading your blog you might be grokking these things intuitively so it may sound I'm spewing trivialities but trust me, in the industrial scale of things - they are not - these are some hard learned facts :)

Ok, now you know for whom the software is and what the inputs and outputs are.

Now we get to the technical bits.

The thing that kills your velocity will be complexity creep unless you take care.

Since you are a software engineer you probably understand what good architecture is, so I don't have to spell it out, but in these types of programs good architecture gets thrown under a bus at some point as the software has basically evolved to an architectural dead end because the team did not anticipate some requirements that manifest only much later in the development plan. Then what happens is rather than refactor the entire codebase (which at this point is usually massive) the team starts to do "clever hacks" to implement the next feature.

Then those "hacks" pile up and you end up with legacy software like no other, like I would guess most of Autodesk's or Trimble's portfolio is composed of.

Why dont't they just fix things? Well, then the user space equivalent of Hyrum's law kicks in.

At this stage you are either default dead or have bunch of industrial projects humming on your software.

And industrial users _don't appreciate change_. They prefer 99/100 times a software whose bugs they understand and know how to circumvent to have the software perform reliably in _their_ design pipeline for the next decade at least (well, figuratively speaking - in any case you need to commit to _support_, _maintenance_ and _not changing critical things_).

One point of view to all software is that they are discovery tools for end user requirements.

The problem with CAD is that the entire stack is so complex that when you get to your mvp:s using the software successfully, it's already so complex you really don't know how to fix it anymore without writing it from scratch or breaking things.

I think the above makes clear why I'm quite bullish for you and hope you keep up with the project.

But the architecture will stab you in the back so many times unless you prefer the "gray goo" model of software architecture. There's no manual for this. Just keep at it. Why can't someone tell you just what the problems are? Because they are emergent. Because you are doing a creative thing and not just copypasting some boring-as-hell SaaS app that's Crud-with-sugar-on-top.

In general I agree with the overall software architectural sentiments you wrote about so looking good so far :).

P.S. Of course 3D modeling, good UX and all that stuff is really hard if you look at industrial baseline on what things are "easy" or "hard" for people, but that's the table stakes stuff which you need to also to cover.