5 ms·

[Disclaimer: my company is using Superblocks and have been paying for it for about a year] Been reading the comments and I think there are a bunch of questions

[Disclaimer: my company is using Superblocks and have been paying for it for about a year] Been reading the comments and I think there are a bunch of questions about why companies would use a tool like this and that integrating your product / company into it is potentially risky. Here's why we decided to use it. First thing you should know is that before we moved to Superblocks, we were using a combination of Retool, Google Cloud Scheduler, Mode Analytics, and a few small Google App Engine apps to solve our problems. There is a whole ecosystem of apps and mini-products our engineering team has to build which require slow-paced maintenance, but are still mission critical to our business. Analytics dashboards, Slack reporters, revenue dashboards, customer service dashboards, Discord bots, etc. There are plenty of different tools which solve some of those problems in silo, but the main problem (and beauty) of building internal apps is that you can fully solve for your unique business problem. We're a tech-enabled advertising agency (there are a handful of companies like ours in the world) and we both have our own external product as well as a series of internal apps that power our operations. We decided to move all our internal apps to Superblocks effectively because we could merge a few different platform layer things (Google Cloud Scheduler, App Engine, Mode, Retool) and be able to build much faster within our team. The big thing for us was that we have engineers writing in Python (more data heavy stuff), and engineers writing Javascript. Previously, we had to have them offer APIs to each other and it wasn't as agile as it is today for simple things we had to build for our business stakeholders. I remember seeing one of our first Workflows on Superblocks when our data scientist built a BigQuery step, a Python step, and then our Javascript engineers grabbing that to do some post-processing with it to display the data and thinking "this is probably how most tiny apps will get built in the future". I don't want to have infrastructure for every tiny solution I built for our team. I just want things to work.

verdverm 4y ago
As a developer, the other concerns that I always want to be addressed around RPA / UI based tools are (1) how do I solve my problem when it outgrows the bounds of the product, yeah, you kinda have custom code I can enter via the webpage, but... (2) why do I have to use & learn your UI, let me use my normal tools
- bradmenezes 4y ago
  Are you looking for specifically to write code in say your own IDE like VSCode and we build a VScode extension?
  - verdverm 4y ago
    I use nvim, but yea, that is the point. Meet your users where they are, which is code for developers, not drag-n-drop, which is for non-developers. Pick your poison :] Just to be clear, porting a drag-n-drop interface to VS Code is not meeting developers where they are.
    - bradmenezes 4y ago
      It's a great point, one interesting thing we've found is that backend developers are welcoming of using a drag and drop frontend builder, as long as it is extensible with code. For them using React, HTML, CSS is painful especially for an internal tool where the speed of getting their tool shipped is paramount.
      - verdverm 4y ago
        Do you have analytics that back that up, or just statements and surveys? As a backend focused dev who's very interested in low code, I've tried them all and they fall short after the honeymoon. Most recently Plasmic.app, had (has) great promise once their product matures. They nailed the developer facing workflow. The problem is twofold, (1) that the UI is big, slow, and buggy (2) the code that comes out the other side is super heavy. A blank component added 50% to my bytes shipped. The hard question to answer is what does that interaction point look like? Why is the backend dev even tasked with doing the frontend? You'll face a point where you will have to decide who your paid product is for, and every drag-n-drop for developers has pivoted to non-developers, because getting something that most developers actually love has proved impossible to date.
        xyzzyrz 4y ago

verdverm 4y ago

As a developer, the other concerns that I always want to be addressed around RPA / UI based tools are (1) how do I solve my problem when it outgrows the bounds of the product, yeah, you kinda have custom code I can enter via the webpage, but... (2) why do I have to use & learn your UI, let me use my normal tools

bradmenezes 4y ago
Are you looking for specifically to write code in say your own IDE like VSCode and we build a VScode extension?
- verdverm 4y ago
  I use nvim, but yea, that is the point. Meet your users where they are, which is code for developers, not drag-n-drop, which is for non-developers. Pick your poison :] Just to be clear, porting a drag-n-drop interface to VS Code is not meeting developers where they are.
  - bradmenezes 4y ago
    It's a great point, one interesting thing we've found is that backend developers are welcoming of using a drag and drop frontend builder, as long as it is extensible with code. For them using React, HTML, CSS is painful especially for an internal tool where the speed of getting their tool shipped is paramount.
    - verdverm 4y ago
      Do you have analytics that back that up, or just statements and surveys? As a backend focused dev who's very interested in low code, I've tried them all and they fall short after the honeymoon. Most recently Plasmic.app, had (has) great promise once their product matures. They nailed the developer facing workflow. The problem is twofold, (1) that the UI is big, slow, and buggy (2) the code that comes out the other side is super heavy. A blank component added 50% to my bytes shipped. The hard question to answer is what does that interaction point look like? Why is the backend dev even tasked with doing the frontend? You'll face a point where you will have to decide who your paid product is for, and every drag-n-drop for developers has pivoted to non-developers, because getting something that most developers actually love has proved impossible to date.
      - xyzzyrz 4y ago