[swman]

Hm.

So again forgive my ignorance here. I formerly worked at a unicorn startup that exited some time ago, so I've not worked at FANG or something huge like that, but definitely at a company that needed to pump out tons of features fast for both internal stakeholders and external users.

For user facing stuff we eventually developed a design system so fair enough, don't need retool or something there.

For internal facing stuff, before our design system was built, we'd literally just use mui (or bootstrap, or even bare bones) and react and put together whatever tool Sales/support/etc. needed and it would be live in like a couple hours max. I could access any streams or databases easily, and put a simple UI around whatever. Things like a need to load up customer information from sfdc instance A and cross reference it against data in live customer db, and call out any data (like phone/email,etc.) that didn't line up.

Wouldn't it be easier for a full stack engineer to just code it? Or am I missing something? I mean drag and drop + set up interactions + pull from database + write to database + other things via a UI seems more time consuming than just writing 100-200 lines of code.

How do I get access to my customer database in this tool and salesforce instance? What if I need to check a user's account information via our account service to see if they have access to some additional paid features? Would I even want to connect a live data store to this kind of tool?

Sorry if I'm rambling, I am just confused if this is a valid use case or not. Or is it just to make basic forms?

[ruslan_talpa]

Over the time (as part of researching competition) i also hear a lot of fans of retool with rave review (though never specifics as to what they are using it for). And i get it's appeal for building the UI, drag and drop, you see it directly and all the props of all components are there in the UI with documentation. But putting together the UIs is not what i find hard (using libraries like Reach-Admin). For me it seems way more time consuming having the UI interact with the actual backend/db and when i see in retool that this is done by "write a bunch of SQL for each table/button/screen" and they are just there in a list ... i just don't see how this is scalable/manageable for a internal tool with 10-20 screens. Also all the input validation is on the frontend ... did i miss some docs somewhere?

[kinj28]

Not every retool like tool is meant for building single page apps. For instance in our tool you can build complex multiscreen apps. Infact one of my customer built a CRM and 1 year into it they have something equivalent of sales cloud + marketing cloud + service cloud . he says. Hubspot would have costed him a fortune for the same thing. But today they are much happier given the control they have on their CRM. One downside - out of the box integrations with systems like outreach or LinkedIn. But as we speak they created their own outreach with again low code and I think they are doing fine.

So long story short - these tools are incredibly powerful to build complex business apps at breakneck speed.

[kinj28]

A response to your use case:

- you deploy an on prem instance of the tool - you just connect to the data sources like sfdc or sql or whatever data sources via the connector layer - you drag drop and build Ui super fast and bind data in a jiffy

Net net - your time saving would be around:

1) no need to create APIs or anything to connect to your customer db 2) no need to figure sfdc custom APIs 3) no need to add any specific DB sdk in your app and figure using them 4) build Ui real quick. 5) write your cron jobs or microservices really