[shrimpx]

That's cool, it's kind of like Scratch [*] for business. Presumably the market is people who don't like Retool because it is too high-level (not enough control) and don't like code because it's too low-level (too much boilerplate and tool complexity).

The risk is that the finer grained control stuff is too much like code ('you lost me at "loop" and "condition"', etc.), or not powerful enough to do the tasks that Retool isn't good at, without diving deep into the weeds, and you're not as good as Retool wrt the tasks that Retool excels at.

Definitely cool that you can extend it with code, though I haven't parsed how that works.

[*] https://scratch.mit.edu

[frankgrecojr]

I'd love to hear your feedback after taking a few minutes to try it out! We think this will be easy enough for non-developers to grok while also flexible enough for engineers to do whatever they want.

[lstamour]

Seconding the comment above, I think "Loop" might actually be a technical term and something like "for each (whatever)" or "do X times" might be easier to follow. As programmers we know things like while loops and end conditions, but regular folks might want to see something a bit more human readable. Alternatively, maybe some kind of flow chart with a line pointing at itself might convey what a loop is - that end conditions are lines that leave the loop's outer box and otherwise the loop continues through the line that points to itself. I sort of feel like "loop" and "booleans" are technical terms that people don't understand as easily as simpler terms like "for each". I'm not sure how you could make something like "x < 5" simpler though. That's basically math and you might have to point folks to YouTube videos about inequalities.

Maybe you'd have more than one person setting this up - the engineer could write some of the details with the help of technical docs for the non-techie, but then someone experienced could provide someone less experienced with comments to follow or higher-level descriptions of blocks? E.g. At a high level there could be a human description that says "Load data: While there's more data to fetch ..." or "For each record, relabel fields..." but at a low level, it might say "While len(response) > 0, fetch data" or "Assign object fields x,y,z to response fields a,b,c".

[frankgrecojr]

This is great insight. Taking a more "technical" approach has its tradeoffs but so far, our customer discovery points to this being a tangible approach to try for enterprise use cases. We find that a lot of enterprises assign engineers to build in Superblocks but rather than a team of 100 engineers building out a DIY solution, they can reduce it to only a handful.

I am excited to experiment with in-product guidance and a/b test copy so that we can make things just as intuitive for those who may not be as technical.

[jfoutz]

Maybe take a look at cobol.

I know, I know. But it was designed for non programmers.

Their syntax in this case is

Perform . . . Times

The language might give some insight by offering a different perspective

[frankgrecojr]

TIL! That syntax reminds me of Ruby a little bit.

[eitally]

I think "Scratch for business" is an excellent way to think about Superblocks. Like IFTTT or Zapier but with an orientation toward what the old promises of JBPM and similar used to make but could never deliver on. If you can empower non- & semi-technical business users to create workflow apps that will either create eliminate enormous headaches for IT.

[frankgrecojr]

I agree. Today we help IT teams solve this with our integration level RBAC but there's a lot of interesting ideas brewing internally for this very problem.

[mdekkers]

Looks cool, but you lost me at the SSO Tax on your pricing page.