For example, here's when we launched: https://news.ycombinator.com/item?id=14515494. Hilariously, we described Retool as "Excel with higher order primitives", and people understood it! (Only on HN!)
After that, we spent around a year polishing the product and getting customers, and we launched officially on HN: https://news.ycombinator.com/item?id=17725966.
Today, we have tens of thousands of paying customers, are ~cashflow-positive, and have substantial revenue. But we are yet still so far from changing how internal software is built. Our thesis is that a Visual Basic-like application builder is a better way of building a certain segment of software (namely, internal CRUD apps). If you have any feedback or ideas on how we can improve the product, please do let me know (in comments or via email).
Oh, here's our blog post too: https://retool.com/blog/series-c2/. It has some details about our weird fundraising strategy (smaller rounds, lower valuation), which we think is more employee-friendly (lower dilution, more upside for employees). Happy to talk through that as well; here's another article about it: https://www.forbes.com/sites/alexkonrad/2021/12/22/retool-un...
Demo tips: Name your queries. Following along "query1, query2, query3" is confusing. You should following best practice (where it makes sense) during demos, and you're definitely not doing it.
The selling point of this tool shouldn't be for the developer, it should be for the manager. So add some "here are some other examples of tools we've created in a similar amount of time through a similar process" - then have UX's for different companies, industries, regions.
Non-technical management need ideas. This demo doesn't give it beyond "hey look you can create a button to update a table". So what? Every ERP and CRM SaaS has that!
We spun up the prototype in a couple of weeks without much hassle. It was a huge success. so much so that the customer who we created the prototype for decided to invest 6 figures into our business.
it's 6 months later, albeit we've outgrown the prototype, I've learnt valuable lesson in prototyping fast, like as fast as you can and get it out the door.
looking forward in seeing what retool can become next. more stability, or ability to write/perform some automated testing would be amazing.
Coming to CI soon as well: https://docs.retool.com/docs/testing-in-ci
Thanks for being a customer! Glad that it worked out for you and your team :)
Hopefully this is something money can fix :)
the problem was the sum of UI latency to US(?) plus latency of serial API calls to get the data. We could probably have lived with a full rendering time of 100ms or so, but responsiveness requirements don’t scale linearly. So with a few round trips, it quickly became insurmountable.An alternative is our self-serve on-premise product: https://retool.com/self-hosted/, which you can host in your own EC2. Given this latency issue is our fault, if you want a discount, just reach out to me; I'm david AT. Happy to provide a discount until we go multi-region with our backend.
I wanted to follow up on the above. Solving the round trip problem David mentioned above involves multi-region for our entire backend, inclusive of our DB. This is definitely a priority and something we plan on having by EoY.
Another topic of interest is managing queries. What happens if a database column is renamed for example? Now we manage it though stored queries in our db - this creates some dependencies and there is always a risk that old queries are no longer used or some query has not been updated. A single place to manage and overview all queries would go a long way (maybe this exists, I have only had a small part in the implementation).
We don't manage the database for customers; we instead connect to your data (whether it's behind an API or database). That was one of the first decisions we made — as a developer, if my data is already in postgres, I certainly wouldn't want to have to ETL / sync it anywhere. :)
Use cases: probably our most common use case is a CRM for a consumer company (e.g. Doordash). The reason that is so popular is because if you have (say) 1M orders a day, you aren't able to put that data in Salesforce anymore. And so the only way for you to manage all that stuff is by building custom software (instead of buying anything off the shelf). Retool is good at that: you can build CRUD-y screens very quickly. Retool, today, is not good at making everything pixel perfect (e.g. we have a grid layout engine, and you can't break out of the grid), but a CRM doesn't need to be pixel perfect.
Any reason you pivoted away from that product? I quite literally am in search of a company that will do this that doesn't also want to be our API provider in production.
EDIT: I also want to point out, I really like how mature the product has become from the time I looked into it last (I wan to say maybe a year ago, maybe year and half). Seriously considering replacing some internal admin functionality with it.
In the future, we'd love to make it more robust; we're currently working on a database-y product (think Airtable, but backed by postgres). It would be really cool to have mock data-generation built in to that product.
a) Is this for rapid prototypes? (web? mobile?) b) Do you have a microservice architecture and you want to mock out one of the services? (dev? ci?) c) something else?
Lets say the generator looks at your schema and generates an api, how much would you want to tweak/customize that api?
Is the mock api returning data based on what's in the database? If so, can the mock api mutate data in the database?
I've been really interested in trying retool since my head of ops pointed me to it a few months back. I think it should meet my use-case but I'm not entirely sure.
I run an experimentation program and I think retool might give me a way to build views on experiment performance for me and my stakeholders, but what I think it may be missing is some way of running statistics on the data, perhaps using python or R.
Data "about" my experiments (descriptions, tags, dates & times, stakeholder details etc) lives in airtable. I think I can get that into retool using sequin, right?
Performance data lives in bigquery. Sessions, clicks, conversions - all that stuff.
Right now I build ad-hoc reports in R/excel/data studio but as our velocity increases I need to streamline this.
I think what I'd like is for a stakeholder to be able to select the experiments and timeframes that they're interested in from a list, then behind the scenes the ID details to then be used to run a query in bigquery and that to pull back performance data. I'd like to show that in charts and tables on screen with how much impact the experiments have had (I think so far this should be reasonably straightforward with retool), but crucially I want to calculate confidence bounds for each metric.
Is there any way of bringing Python or R into the data flow somehow to do the heavy statistical lifting?
Am I looking at this the wrong way? Should I be trying to pre-calculate this nightly as some sort of scheduled job and just use retool as a presentation layer?
While we don't currently support using Python or R in apps, we do have something new shipping soon that'll make it easier to run heavier statistical lifting server side. If you're interested in a beta access, or even pairing on a build session, let me know at jane@retool.com.
Also, I think pre-calculating values and storing them in a database table is a smart idea if your velocity is increasing and you want folks to be able to access reports themselves. Your users will get a snappier app and you'll have a historical record of experiment results to reference.
I believe AppSmith is a FOSS alternative, otherwise.
The best thing you can do is what you've already done. Post about it publicly, let your AE know.
Hope Appsmith, Budibase, Tooljet, Bubble, et al work out!
Oh, while we are actively thinking about pricing, if Retool is out of budget for you, please do reach out to david AT. We are always happy to be flexible on price; our goal is to convince more people that Retool is a better way for building CRUD software, not to maximize revenue. We never want pricing to a blocker for anybody. (Reaching out to me is obviously not a long-term solution, but is a good one while we think about what our future pricing plans look like.)
TBH, fundraising is kind of like charades: it's a way to signal you are doing well, without telling people your private company metrics. I wish we never needed to fundraise, and could just focus on building great products and working with customers instead. :)
I hate that this is the answer.
Edit, for clarification. I don't hate that this is Retool's answer, I hate that this is how the world actually works.
A suggestion: if you want to really show progress and get a lot of press, do a buyback from employees/early investors instead. Signals to the world the level of confidence you have in your own stock.
They already were investors from previous rounds.
I think it’s hilarious that the reasoning for fundraising is ‘free publicity’ here though :)
In this case, small by rapidly growing.
In the case of a thin margin retailer, cash constraints, working capital etc. imply need for funding.
and the people that bought in wanted some exposure, like really wanted some exposure
Whist it might comes with downsides and limitations I think the positives in terms of time-to-market and cost outweigh these on balance for many types of needs (not all for sure).
Congrats.
Code when a ceiling has been reached with existing tools is the future — a ceiling which is getting higher and higher, thanks to Retool etc.
Why would people building software today need to do that? There are excellent, “batteries included” polished versions of plenty of the things we need to build software: package managers, developer tools, machine learning libraries with the latest algorithms, testing & CI/CD tooling, UI components, web servers, databases, etc. There’s even entire applications that are FOSS, if you want to build a new tool there’s nothing stopping you from adding whatever you want to a pre built FOSS application like LibreOffice, Calibre, etc.
https://www.worklife.news/talent/developers-are-burned-out-q...
we use Microsoft PowerApps.
i see it differently. if you build too much internal software/tools on PowerApps. your company is tied to Microsoft for a long term since there is no easy way to jump from PowerApps to another low code platform without redo.
Vendor lock-in is just the price of using a vendor, and one which is often overwhelmingly worth paying. What you are saying is true, but it's not really enough of a detraction to justify building everything in-house.
10% of the code we write produces 90% of the value: retool etc. allow us to spend much less time on the 90% of code that isn’t valuable to the businesses we work for.
I don't think there is any novelty here except for it being on the cloud. I also don't think this a no-code platform.
On top of a drag and drop visual builder, Budibase comes with an automation platform (like zapier) , internal db, and a lot more flexibility when it comes to design.
We launched our cloud product 7/8 months ago and we just hit the 40,000 companies using Budibase.
Budibase is open source and you can run it on Docker, K8s, Digital Ocean, Raspberry Pi, ARM, and more.
If you are interested, check it out:
https://github.com/Budibase/budibase
To David and the team at Retool - congrats! I'm the cofounder of Budibase and it's wonderful to see you push the industry forward. But we're coming to get you :-)
Retools UX is different from Budibase. Budibase separates the dev process into 3 stages; data, design, automate - where Retool is sort of like visual basic (everything in one). We used Visual Basic a lot in previous roles and we decided we could build something uniquely better.
One other thing Budibase has is a public API, which allows you to use Budibase as a backend (with different frontends including Next js, Svelte). It's also great for inter-operability.
With Retool, you must write JS to build an internal tool. With Budibase, writing code is optional. Our main goal with Budibase is to make it as accessible and flexible as possible. Open source is a great driver of this.
Once again, it's been a while since I touched Retool and it is a very solid platform and I am sure there are more things it provides over BB.
Budibase is tackling the same problem in a different way, from being open source and a different UX, to barrier to entry. We feel this is a better strategy in the long-run.
Our subscription is now up for renewal and it looks like we're in for a big price increase as we transition from a handful of shared users to 50+ named users + granular permissions. We're still a very small startup (<5 developers but lots of external customer service people using Retool) so hopefully we can find a way to take the company size (and not just the number of seats) into account.
Looking forward to continuing to build on Retool!
Glad that Retool has been useful for your internal operations and support teams. I work with a number of our banking & fintech customers and would love to see what apps you've built.
I also want to make sure that you have what need as you head into renewal with more users. Mind shooting me an email so I can connect you with the right people? I'm alex[at]retool.com.
I've always been interested in Retool, but have a baseline requirement of any tool syncing back to Git. Is there a reason you don't allow that in the SaaS version?
If you do end up implementing it, I'd love a heads up: me@morgante.net
It depends on your use case: Metabase is designed for BI (i.e. reading large amounts of data and chating it); Retool is designed for apps that write back to databases / APIs. Metabase (TBH) is better at charting (they have nicer charts, better caching, etc.). But it doesn't support writing back to APIs or databases. For example, if somebody on your team is asking "what was our revenue last month", Metabase is going to be better for that. But if your team wants an app that "shows possibly fraudulent orders, with a button to cancel & refund them", Retool is better for that (and Metabase wouldn't allow you to do that).
We're very much solving for the BI usecase right now but as we start staffing up the ops part of our company, we're not going to be able to build all those internal tools ourselves. Looks like Retool would step in there nicely.
It's got a few things Retool doesn't too
SMB need little more than this. They could run for decades.
Having said that, the commercial model of Retool doesn't work for my use-case so I use Appsmith now which is also incredible!
EDIT FTFA >>>The funding, which Retool has described to me as a Series C2, is coming from Sequoia Capital, Stripe co-founders John and Patrick Collison, GitHub’s former CEO Nat Friedman, Elad Gil, Daniel Gross and Caryn Marooney, the former VP of Comms at Facebook who is now a partner at Coatue. All are previous investors in the company. The round comes on the heels of the company raising a more modest $20 million Series C in December 2021 (which valued it at $1.85 billion).
I don’t know what N should be. People seem to generally accept its < 10, possibly < 5. But at N=1 it’s definitely too small of a sample size.
The user is pretty different too, Airtable generally targets business users who may otherwise reach for a spreadsheet, whereas Retool is focused on developers who might otherwise reach for React Admin (or something).
The build process took a bit of time and I had to hire an expert on Upwork. Not everyone might persevere. A gallery with examples of varying complexity would make the sell easier.
I think retool is a great framework to build internal apps. Customers always wonder of what they can build with a framework. I wonder what were strategies that you used to solve this problem.
