I've been working on something that might be worth giving a try! [1]
It's built more for specifically for software architecture rather than general whiteboarding, but we just recently added custom icon uploads so you could add whatever icons you want if you're more interested in hardware. The 'logical component' operates in two modes, one which is just a group, and one where it acts like a sub-board that scales its contents to fit the box.
My understanding of it is that HN/YCombinator would also have to be targeting EU customers directly, such as by offering the service in EU languages (english probably wouldn't count) or offering prices in EU currencies.
On my first pass of the title on the front page I figured this was going to be a Legend of Zelda game... This article is not as fun as LoZ, not even in the slightest.
Their main product is an Enterprise Service Bus, a piece of technology that is supposed to help make it easy for software developers to integrate with multiple disparate third party solutions (and potentially internal solutions). So you can get a "Connector" for SAP, and another for Salesforce and consolidate, transfer or do practically whatever with the data in both systems, without having a bunch of developers working on an in-house solution to consume the requisite APIs.
My one criticism of them would be they focus very heavily on cloud, and their on-premises offering is woefully anaemic, lacking fundamental functionality, such as messaging.
Don't worry about the code looking dirty, embryonic code always does. If it's a big enough tool it may warrant setting up a GitHub Pages site for it, just to make it a bit easier to find when somebody is suffering from the same problems you were.
In terms of new features, once you've put the repo on GitHub (or wherever) other people will likely suggest features as issues or modify the program themselves (and hopefully open a PR).
I would start by kicking off the process of codifying your knowledge. I've used confluence for this, and it's a real art to sit down and work out how to structure your information, the level of detail required, and what should be documented in the first place. I've found that the people I've worked with the went from a technical to managerial role were mostly relied on for that vast technical and organisational knowledge that they had built up over the years.
I'm not sure if you're managing a project, product or divisional team structure, but I would say that no matter what level you're attempting to manage, set some sort of vision for your team to align themselves with. This can cover things such as technical aspirations, or organisational strategic goals.
Trust your team. It doesn't sound like there is any mistrust in your team, but I understand the difficulty in getting over that initial knowledge hump when introducing people to a new domain, especially as an "expert" in the area. Documenting knowledge in clear and concise ways, and making different members of your team experts in certain areas of your knowledge will help them to become more self-sufficient in their quest for knowledge and answers. Consider this an investment.
As a general piece of advice, not aimed at any particular part of your post, you were in the same position as your team members are now not long ago, think about the pain points you had and try to learn from them.
That works under the assumption that humans are purely rational beings, which we are not. Though I don't necessarily think the design chosen was a great choice based on other comments here. Maybe something a bit more generic, yet still colourful (like the candies in games like candy crush) would have been a better choice.