Business and PyRevit custom

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.

  • No warranty
  • no one can really be made accountable if something breaks
    Big AEC firms hate this for many good and bad reasons. IT governance/compliance/…, security, accountability, …

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

2 Likes

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 :grin:

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.

2 Likes

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.

1 Like

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 :

  • a C# code is not eternal, you have some revit update wich can give him obsolete. Remember the new floor parameter in 2020 (21?) and the adding of the plumbing equipment category. If the customer has the open source pyrevit (and the knowledge) he can update by himself, on C# he need to contact the code creator. In this case he will pay you again or you have a forever maintenace contract ?
  • An open source and non compiled pyrevit custom tool can be shared easily but a script that is created for a very specific task that only one company can benefit (unique process, unique parameter name…) has no value to be shared.
  • I don’t know C# but python is very efficient for databases and Revit is one, so it make sense to use python for manipulate them.

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 :slight_smile: :sweat_smile:

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:

  1. There is a way to compile the python code for IronPython engine and embed compiled DLL(written in any NET programming languages) as a part of pyRevit as extension. And in this case it’s going to be obfuscated even better than the C# code. Little do the clients know that dlls generated with C# code could be easily decoded with such tools as JetBrains Peek :grinning: So, it actually feels like a big general misconception about the security and code protection, but became a standard.
  2. pyRevit supports loading and executing dlls, but it’s struggling updating with “Update” button since it relies on GIT which doesn’t like binary files, hence making this way of delivery not viable for enterprise users. Improving this workflow might bring more people on pyRevit side. Also, as @eirannejad shared before, new features like bundles could be implemented or the idea with the “extensions store” where everyone can share their feature like a file.

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.

5 Likes