If doing the first versions in this thing meant you got to that position 6 months earlier than you would've otherwise, you shouldn't wish you'd just done it in Python from the start - your business would be missing even the functionality it has now for another six months.
You will, though, need to get creative and figure out the fastest way to get something close enough to X to make them happy in the tool, or with a hybrid tool+adhoc script approach, etc, though.
So there's still a lot of benefits there to knowing the fundamentals.
it is also geared heavily toward internal software, so it has a very narrow scope, it's not really for startup, it's not really for large enterprise with their it deps, it's not really for jim in accounting with his excel honed trough year of hard work...
it will find a niche for sure, but the harder part of the use case it covers is modeling workflow interdependencies and that complexity doesn't lie in the software
If you have access to only engineers, why would they learn this new non-code tool? If you want an application that meets a very sparse, loose set of requirements, just get them to create it using their normal tools -- it won't take relatively long.
If you have access to both engineers and business folk, there's no reason to have the businesspeople write such a requirement-lax application using a non-code tool, since if all you really want is an MVP that doesn't really meet your requirements, get the engineers to do it -- I'm sure they'd be happy with the freedom to throw requirements out the window. And then when you want to expand on it and flesh out those requirements, the engineers don't have to port the whole thing over from whatever proprietary non-code tool the businesspeople could have used.
If you only have access to nontechnical people, you're kind of screwed. Sure, you can have business-savvy folks whip up an MVP using one of these tools, but then when you want to expand on it, what do you do? You need technical people somewhere in the pipeline to make this work. If you didn't have access to engineers in the first place, this is the juncture at which you could hire some to port the application, but is the technical debt you've introduced worth it?
I don't know -- tools like these seem to target aspirational nontechnical people who don't have the foresight to think two steps ahead.
A MVP is quite often exactly what these people need to get the bosses engineers working on the right product. And often it's not enough and the business folk end up using Excel for 20 years with a string of failed products coming out of engineering.
As a programmer, I'm very lucky, but none more than here. I have access to an infinite amount of programmer time. Okay, realistically that's bounded by the number of productive hours in my life, and more realistically, my level of interest in a thing. But it's easy for me to tell someone else "oh yeah, just get a programmer to do it" - because if I had those same desires, that programmer is me.
But looking at the job market for programmers and the salaries commensurate with the demand for them (both in and out of the Valley), "access to a programmer" is something that many people still have to reach to get, and "learning to code" is not a quick or easy process. Honeycode isn't the first product in this space, nor will it be the last.
