The Process and Challenges

This one started out of frustration more than anything else. Sijb and I kept running into the same problem on our projects. Files everywhere, inconsistent naming, exports in the wrong place, old versions mixed in with new ones. It was slowing us down and it was the kind of thing that gets worse the bigger a project gets. At some point it made more sense to just build something to fix it than to keep dealing with it manually.

So I built a custom 3D pipeline tool, something we could actually use in our Blender workflow to keep projects structured, automate the repetitive stuff, and enforce a consistent folder and naming system across everything. The goal was simple in theory. In practice it took a lot longer than I expected.

The hard part was not writing the code, it was thinking through all the ways it could break. Edge cases, unexpected inputs, files not being where the tool assumed they would be. A lot of the development time was just debugging things that worked fine until they suddenly did not, then going back and rethinking the logic behind that part of the system. There were moments where something I thought was finished turned out to have a problem I had not considered and I had to pull it apart and rebuild it.

Getting the workflow logic right also required thinking carefully about how we actually work, not how I assumed we worked. That meant going back and forth with Sijb a lot to make sure the tool actually fit the way we use it rather than forcing us to adapt to it.

What I Learned

Building a tool that is supposed to support someone's work is different from building something that just functions. It has to be logical, fast and get out of the way. If it creates friction it defeats the point. Thinking about it from that angle, as something a person has to actually use under deadline, changed how I approached every decision.

I also got a lot better at breaking a problem down before writing anything. The times I jumped straight into building something without planning it properly were always the times I had to go back and redo it. The times I sat with the problem first went better.

Next Steps

The tool works and we use it, but I know it could go a lot further. There are features I cut for time, things that could be more automated, parts of the interface that are functional but not as clean as I want them to be. I want to keep building on it. Not because it is broken but because I can see clearly now what a better version of it looks like.