Checking out page source and a few network requests, I came up with two more ideas!
Save some hosting money and bandwidth! It looks like each rack view is loading both the "thumbnail" WebP rack image for each module as well as the full-size PNG that is shown when you click the magnifying glass in the hover-tools. For my 6-row, 150U wide cabinet, that's a total of about 7MB. On subsequent page loads that gets smaller (hooray, cache!), but it seems like it'd save time for users and money for you to only load the full-size images on-demand, when the user actually clicks on the full-size magnifying glass. It looks like the gear.svg file is loaded on-demand when I move a module -- same concept could save a lot of network bandwidth for your site and your users.
ModularGrid API for Unicorns! The rack data is embedded in the page server-side (it seems like), rather than loading with a separate
GETrequest; moving a module happens over aGETrequest to a path that acts like loading amove.jsonfile, rather than aPOST, etc. The great thing about an API is you could offer developer access to Unicorn accounts: An API key that paid accounts could use to build their own UIs, add their own UI/UX features, etc. The APIs could still require a valid user login/session (so that MG still controls feature access and user accounts), and if you asked Unicorns to enter the URL to whatever they build, you could check their work out and learn from whatever they build. Modular Grid As A (paid!) Service! Another cool thing: you can build a new API server separately from the current site, if it's too complicated to convert the site to web-client-and-backend-API-server — https://api.modulargrid.net/ or whatever — and use the same image-store and database(s) as the web site uses.