Hi,
I’m asking myself about the viability of being able to setup up some pyrevit custom tabs as a business plan ?
I’m sure this is always useful to have this skills whatever you are using Revit but how companies are ready to pay another company or an independant for this job ?
As an independant can we have 100% of customer or we need to mix with other tasks ?
Yoann
My 2 cents
Or the elephant in the room.
Tldr;
Unless you are a marketing pro, not viable as a primary activity.
In the past year, I did 2 specific jobs, very small stuffs, a few hours. First one in March '24. Nordic huge engineering company. Never got paid. 10x emails. And the invoice was very small. Second one, hopes and spirit high, I should get paid next week or so.
Better chances are proposing this as a part of a broader services range. Bim implémentation, software training, support, project management, technical support…
I would happily make pyrevit my day job, but it does not look nor feel realistic.
Some of the reasons are inherent to pyrevit being a non-commercial solution.
End of the day, pyrevit is being used by probably 100k+ users of Revit. Users love it. Coders love it. Autodesk loves it. Startup/seeds/founders/companies love its codebase.
#anotheDropTheMicMoment #noApril’sFool
Fun fact.
Just approved users from EXP and WSP…
Thanks for the feedback ! At least we can use this for improving our own working process.
I imagine big companies will prefer C# and can afford it. But for small companies I believed they was a need because they can automate a lot of tasks and there is few people who are coding in the AEC field.
After Dynamo is more accessible and maybe this is enough for them.
I will try to probe around me to know why there is no need to have some beautiful and custom toolbar, maybe they just ignore all the possibilities.
Let stay positive !
Just to be clear, there is a need. More often than not, companies in AEC, small to medium ones, are short of money or do not see the value in automation (speedier delivery, less bored employees,…), and setting up, building the tools in pyrevit, While faster than with c# and the whole shebang, still takes time and $. Not the coding part itself, but the ideation, planning, testing, improving, documenting and implementing…
#positiveAttitude 
I’ve been pondering this for some time. I think the only way to leverage this in the AEC market is through Autodesk’s cloud services. The distribution model is the key. You can’t be packaging and sending out python to clients on a traditional basis. I think it needs to be more software on demand. A growing and on going library of tools that the industry can select from. “Give me 3 scoops of structural and a side of parking layout. Next week, I’ll take some annotation. And btw, I want some schedule stuff next month. Can you get that on the menu?”
If you could develop these tools so they were web hosted (protecting the IP of the code) - then I think you could go somewhere. But that’s a bigger lift than just a pyRevit extension. Sill pondering the problem and technology.
I think Dynamo is a dead end. The whole node concept is a Tower of Bable and unsustainable long term. Too fragile. Autodesk likes these Towers of Bable. AutoCAD layers. Revit Shared Parameters. The end user wants button and a click solution.
As someone who has consulted in this space, dynamo and pyrevit are ok for small cases or scenarios where companies accept a degree of dependency and potential that their tool is unlikely to work forever.
Nearly all customers i had eventually wanted solutions in C# though, even if just to keep then obfuscated. I generally only deliver the compiled outcome as well so it means i can keep my general utility code inhouse vs pyrevit/dynamo where you deliver actual code and everyone has it - harder to remain competitive.
Very interesting comments. C# allows to keep the code closed, this is nice for controlling our business as you said but on the other hand :
After I understand giving a msi file make more pro than giving some py files you have to install by yourself but i’m sure you can compile an exe that will make the work for the pyrevit installation. We can imagine our customers are not coders, they just want to install and use the product and don’t care of how it works.
It can also be interesting to test an IA for converting pyrevit files to C# ones 
I recommend giving c# a crack and then comparing. I used to feel the same way, but c# to me is truly the way revit addin dev feels intended to be. Pyrevits awesome but likewise wont be eternal. If revit api changes on us, so must pyrevit, as must our code as the 2025/net core shift showed us.
You can open source c# code easiy, just need to choose to of course. E.g.
Pyrevit by its own nature more easily invites open source collaboration, which is great for people that want to work in this manner and support a great project like pyrevit.
At the end of the day I think it is best to try out what you get time for and pick the best tool for the job at hand that you feel comfortable depending on - it is impossible to escape dependency, but it is important to know and track what you are dependent on - especially when being paid to write and manage code.
Many people would say the same as you did but replacing c# with pyrevit and pyrevit with dynamo. All a matter of perspective.
Pyrevit is itself built with a decent amount of c# code to my knowledge. Truthfully neither of them are database orientated languages vs using a web approach with a parallel db system so you can form queries etc. The revitapi gives us access to methods which let us treat it as one though.
Hi guys,
Let me express some thoughts here as well:
So, it actually feels like a big general misconception about the security and code protection, but became a standard.Even though there is no warranty for pyRevit as @Jean-Marc said, a lot of companies use it as a main tool for their automated solutions to work. Partnering with them and listening to their needs could be a way to go.