Hi HN! I'm one of the creators of Retool, and we're excited (and very nervous again) to be posting this on HN. We first showed Retool to HN around a year ago (https://news.ycombinator.com/item?id=14515494).
When we posted Retool last time, we thought it was a cool idea (visual programming + functional reactive programming). But we didn't really know whether it was useful, and whether people would pay for it.
Since last year, we've been hard at work talking to customers and writing code. We discovered that internal tools (eg. to manage deliveries) is a good use case for a visual programming language like Retool.
Basically, Retool gives you components (textinputs, dropdowns, tables, etc.), and queries (connect easily to APIs, SQL databases, etc.). In a FRP way, they can interact with each other. So your tables can pull in data from queries, and buttons can pull in data from a table's selected row.
When we show Retool to people, they often think "oh! it's visual basic for the web!". And in many ways - it is! Maybe that's something you think is great - maybe not. In any case, I'd love to hear HN's thoughts. :)
Cool idea! We built a lot of internal tools at my last startup (bloc.io) because it was an operationally intensive business. I would have definitely tried this out.
Your premise that most internal tools use the same building blocks seems accurate based on my experience, a lot of it is collecting and analyzing data.
I'd also add that the most underrated cost is maintaining a tool, developers are usually excited to build something new and when they're working in a fresh codebase they can build and iterate quickly. The real pain is when no one has used a tool in a couple months but needs it now, and the original dev has moved on to some other project so there's no one available to update or fix it. That's one of the biggest reasons we started using more third-party SaaS options instead of building our own, even if they were expensive and only an approximation of what we actually wanted.
> I'd also add that the most underrated cost is maintaining a tool, developers are usually excited to build something new and when they're working in a fresh codebase they can build and iterate quickly. The real pain is when no one has used a tool in a couple months but needs it now, and the original dev has moved on to some other project so there's no one available to update or fix it. That's one of the biggest reasons we started using more third-party SaaS options instead of building our own, even if they were expensive and only an approximation of what we actually wanted.
That is a good point - and we've used that a few times in sales pitches. The benefit of Retool is that it's pretty clear what's going on (oh, new column added to table, so let's add it to our KeyValueMap too). And so keeping things up to date requires a lot less context.
Thanks for the thought - we will bring this up more in our sales calls :)
This is definitely true and one of our insights as well. All you need to use retool is basic working knowledge of sql and javascript, so there's no dependence on the original author.
Hi dvdhsu, this looks great. At Thread we build lots of internal tools, but would like to be able to build more. We currently use ChartIO to build dashboards, but some of these have become almost like mini read-only apps that teams use, it would be great to make some of these into something a bit more useful and Retool sounds like it has the potential to be a good fit.
Some questions I would have as an engineer...
1. Where's the documentation - it's not linked to on the site.
2. What's your GDPR policy, we have customer data in our database.
3. Can this do Slack bots? We use them quite a bit for reporting, would be handy!
4. What sort of auth schemes do you offer? We provide limited access to some of our tools to third parties who aren't on our Google Apps domain.
5. What sort of APIs do you support. We have some basic JSON+HTTP things that require a session cookie to use because they are only used in web pages we run, and we have an authenticated GraphQL API. Would these work? How do you handle authentication on APIs?
WRT cookies specifically - even though requests from the browser get proxied through our backend we support forwarding authentication cookies to the browser that is tied to the user's specific session in Retool. (I thought we had written docs for this but can't find them now. Ping me @ david@tryretool.com and I can tell you how we do it!)
David this looks fantastic. I can’t wait to play with it.
Just on the GDPR front, our DB also has customer data. We currently host on heroku. Does the data we pull in / process using retool go anywhere else except for where we point it?
No, your data never goes anywhere. You can deploy Retool and airgap it to prevent all inbound / outbound network connections. Then you can connect to it via a VPN.
I will reach out over email - thanks for the question!
For the Slack bots, a fairly common thing we want to do is regular business updates from either Google spreadsheets (that are very dynamic/scripted) or from ChartIO. Some basic interactivity with those bots would be handy.
Awesome idea. As somebody who wrote many internal tools for a small startup many moons ago (customer manager, shipping manager, inventory manager) Retool solves that pain.
A few questions.
1.) How does authentication to retool apps work? Can I use 3rd party such as Google or GitHub? Is enforced 2fa supported?
2.) Do you support visualizations from data such as graphs and charts?
3.) You mention to allow access to my database we just whitelist the Retool IP. Are there a group of IP's to whitelist? If somebody compromised your service, then they have access to my database. A bit scary.
> 1.) How does authentication to retool apps work? Can I use 3rd party such as Google or GitHub? Is enforced 2fa supported?
Yep - we integrate with Google, Okta, as well as any other SAML 2.0 provider (e.g. ADFS).
> 2.) Do you support visualizations from data such as graphs and charts?
We have a few charts, but that's not our focus. If you're looking to graph a lot of things, you're probably looking for a BI tool like Looker.
> 3.) You mention to allow access to my database we just whitelist the Retool IP. Are there a group of IP's to whitelist? If somebody compromised your service, then they have access to my database. A bit scary.
Yep - there is a group of IPs for you to whitelist. But yes - if you care about security, you should probably be using the on-premise version of Retool. That's hosted by you, and you can control all inbound + outbound traffic. (70% of our customers are on on-premise.)
You must have an MIT engineer on staff judging from the user names in the video :-) Great demo. I'd use this personally to do things like ML labeling for personal projects.
Not sure if you're going to see this but I'll give it a shot: is the per-user pricing per-end user using the tools or per-developer writing/modifying the tools?
Looks really great. Will try it out as soon as I have a use case in mind :)
A small note: shared that in our internal slack and it just displays as a "preview" the domain, title and meta description of your page. I think Slack uses the `og` meta tags too, so adding a more elaborate description and an image would help :)
This is super cool. Retool has come a long way in the short span of time. I would love to connect it with my db and build more integrations/alerts/notifications on top of it.
Holy Crap. This is amazing. Lot of folks have tried to make a general purpose visual programming solution and it always sucks. However, if we narrow the problem to
1. Show some data on a grid based on user input.
2. Let user select a row.
3. Provide different buttons to take actions on the selected row by doing an API call.
Then your tool solves the above problem extremely well (based on the tutorial I saw). And I guarantee you that any organization with tech teams have need to create plenty of such 'mini apps'.
I recently started a new job as a technical lead and I am going evaluate this tool seriously. Due to the nature of the business, we will be prefer an an on-premise solution. Do you have existing clients who use your on-premise solution? How are the updates to the tool distributed? And most importantly, what's the pricing like? Feel free to reach out to me via email.
BTW, you guys have done FANTASTIC job on the main page design/copy. It's been a long time since I saw a product website which instantly sold me on the idea. Well done!
Thank you! In fact, most of our enterprise customers are on-prem. Updates are distributed regularly and you've always got the choice of whether to update. Will reach out!
Cold Fusion shipped with a wizard to build web CRUD apps against SQL databases, which worked, and you could then continue coding from. It wasn’t bad, and came long before Rails or Django admin.
Definitely! You'll find Retool supports much more than SQL databases and Django admin supports a tiny subset of Retool use cases. For instance, most companies find that after a certain scale Django admin apps need to be converted to custom code. Retool is designed makes custom code unnecessary at any scale.
Not having played with it, I love the concept! I'd suggest making the docs more readily available from your frontpage, as it's somewhat difficult to find a link to them.
EDIT: signed up, ran through the tutorial, and I'm suitably impressed. This is a very polished product.
Will you support command-line tools? There's a few places where I can see my admin tools using command-lines to make things happen. Might be nice to be able to spin up a docker instance and run a set of command-line tools in response to an action, or to provide the contents of a table.
A few questions:
- Why is there only support for Google Sheets query on-premise?
- How many users can access an account in your free tier? This might be a way to better segment between free/first tier - add a limit of ~3-5 users before you need to start paying for the service.
Just added and deployed docs above the fold on home screen. Thank you!
- Whoops - we forgot to update that - we added it to cloud a few weeks ago. Updated our docs - thanks!
- Hm - good question! I think there's currently no limit, but yes, that's a good idea as we scale. We want to have a "generous" free tier because most engineers we meet find Retool fairly interesting. And so we want to allow people to play around with, without having to pay us.
- Yes - that's correct for now. Once we have a better on-premise process, we'll open it up! :)
When I was first taken on as a developer in 2002 I worked on something like this, though I was very junior. XML was a thing then and so the "app" stored it's configuration as an XML file. You would alter your app by writing XML. This meant it looked like code and it failed in the marketplace, as people already had code and they didn't see the use of learning something new. Also this XML had to contain SQL, and HTML, and it had URLs in it. So not something a novice could cope with. The next step taken was to try and build a GUI to generate the XML files, but that didn't sell either because in order to do the really good stuff you still had to understand SQL, and HTML, and Javascript and the URL structure. Even if the app was responsible for some of those things.
Projects like these blur the lines between "coding" and "configuring" software, and I think the success of Retool long term will be understanding how to walk that line. The benefit of code is that it allows for greater complexity to be understood meaningfully, and configuration's benefit is that it is easier to learn. I think if someone is expecting to code and gets a configuration interface, that's OK until it limits them, and if they want to configure and end up having to code, then that's a fail for them as well.
Sort of! We've definitely drawn inspiration from them (for example, we borrowed some ideas from their right hand side for editing component properties). But I think we're fairly different.
For example, in Retool, you can make a `PUT` request in a Postman-like GUI. And when you press run, we handle the data flow for you. In Google App Maker, you still have to write custom JS to call APIs or execute SQL queries: https://developers.google.com/appmaker/models/external-data-.... nd when you do call them, you have to worry about error handling, setting `isFetching` states, etc.
Really cool idea, and would completely simplify our internal tools building process, but opening our firewall to allow access to the small scale internal DBs that we would work with is a total no go.
Not to mention that even trying to create a demo for internal teams that would build tools using this with our data would mean miles of red tape that makes it a heavy sunk cost before we even get to the starting line.
If this had some form of containerized app (like Influx Chronograf as an example), then I could create demos that would likely lead to license purchases. But without that, we'll just keep building internal tools with internal frameworks.
Great idea, heavily limited by not having something I can deploy internally without an enterprise license.
The image bounding box labeling widget looks like a hidden gem!
This tool would shine where the dataset has sensitive information or the job is too specialized to use on Mechanical Turk.
Thank you! Yes - a few customers use it for exactly that! Please try it out some time - it's one of our coolest (IMO) components. :)
(There was surprisingly - no good open source library for drawing bounding boxes / landmarking on images. So we built our own - and now every Retool user gets to use it!)
I've been using this for the last 3 months and it's a pretty amazing tool.
We need to spin up tools quickly for our operation teams and this has been a godsend.
The support has been amazing as well. Very quick response times and fixes when we report any bugs.
This seems optimized for creation of small apps (and is also presented very well). But what striked me watching the intriduction video: When you revisit your a written app, it seems hard to understand whats going on and also hard to get a feel for if all functionality have been implemented and works. How does testing your app with this tool work? How does it help with maintaining a written app to lets say add a new functionality (when you have forgotten all about where your data is stored, where it is read from, what your queries where when you wrote them etc.).
How do you actually connect this to your database? Can't find anything about it in the docs. Maybe it's obvious if you log in but would like to know before I try.
Sure! You can either deploy it on-premise or you can whitelist our IP address. (I just realized our docs for whitelisting our IP address is gone, so I'm adding it back in now.)
It's a little confusing - sorry. We recently switched the repository from public to private, and forgot about the Heroku button! We'll get that fixed soon - thanks for the feedback!
We've used Retool extensively for multiple products at our startup. It's a fantastic tool that's gotten us out of trouble many times. David & Anthony are amazing founders as well!
If you ever need to build an internal tool, do give them a look before you decide to build it in-house. Wishing Retool all the best!
Definitely impressive. The short description seems a little vague or misleading to me though. "Internal tools" can mean a lot of different things - deployment tools, testing tools, data management, etc - so I expected something more generic by the title.
It's true - retool can do much of what blockspring does (or blockspring might be able to be implemented in retool). But retool can do much more, writing back data and running arbitrary api endpoints. The range of frontend components you'll find in retool goes well beyond tables too - from the basics of any app (buttons, dropdowns, checkboxes) to more advanced json previewers, forms, and even image labelling.
Love seeing a year of solid effort manifest like this. Nice work!
For every frontend team out there, this should be the goal of your development efforts--to build a component library like this that can be used to rapidly compose any kind of application.
Great work. One of the very few "Show HNs" I'm impressed by at first glance. My team's internal tools are all CLI-based, but if I had to support users who preferred GUIs I'd definitely give this a try.
If you answer my question, I'll tell you where a bug is in your docs (kidding).
Question: Do you use (P)react or some other framework for your components, or have you done all of this component synchronization from scratch?
Bug/Typo (Chrome): I can't click on the "Local Storage" section[0] in the Component reference, and the description for `localStorage.values` is incomplete: "A key-value store with the data with all the".
Thank you, I suspected it was React (I later saw somewhere you will add support for custom React components). Looks like good work man, best of luck to you!
"Gneiss is a spreadsheet tool for using and analysing online data. It contributes many extensions to the conventional spreadsheet model to support using and analysing web service and other hierarchical data, and creating interactive, data-driven web applications."
David reached out to me around 5 months ago with a demo (it was a sales pitch) and I was thoroughly impressed! Very happy to see the product get even better. Good job to everyone at Retool! Will be signing up as soon :)
Congrats on launching, David + team! So great to user test a few weeks ago — everything from landing page plus onboarding flow seems to have come a long way since then. Keep up the good work.
Congratulations on launching, the professionalism and communication from these guys are second to none. Now to go find and read the Slack bot integration!
The frontend is standard react + redux + a lot of customization. A lot of the engineering effort is in the library of components and database connections we've built up.
looks pretty cool! I'm glad you built something great in the past year.
We build a bunch of tools on top of React-Virtualized which is a brilliant framework (by one of the core devs of react). But obviously what you have is a brilliant end-product.
Yes - we have 2 customers who are HIPAA-compliant, and who use an on-premise, airgapped version of Retool. I don't see an email in your account - do you mind dropping me a line at david@tryretool.com?
Thank you for your kind words! Yes - dragging and dropping + resizing is one problem we should spend a lot of time improving. It currently works... but we could probably make your Retool experience a lot better by just improving that, haha.
When we posted Retool last time, we thought it was a cool idea (visual programming + functional reactive programming). But we didn't really know whether it was useful, and whether people would pay for it.
Since last year, we've been hard at work talking to customers and writing code. We discovered that internal tools (eg. to manage deliveries) is a good use case for a visual programming language like Retool.
Basically, Retool gives you components (textinputs, dropdowns, tables, etc.), and queries (connect easily to APIs, SQL databases, etc.). In a FRP way, they can interact with each other. So your tables can pull in data from queries, and buttons can pull in data from a table's selected row.
When we show Retool to people, they often think "oh! it's visual basic for the web!". And in many ways - it is! Maybe that's something you think is great - maybe not. In any case, I'd love to hear HN's thoughts. :)
Here's a 3 minute video demo I just made this morning: https://cdn.tryretool.com/approval_video.mp4 of me making an approval workflow in 3 minutes
If you're curious how it works - here are the docs: http://docs.tryretool.com/.
Thanks!