Thank you for your feedback (seriously!). I myself talked a few users that shared your point of view last year and that's why we ended up changing our pricing.
I do think there is more work for us to do — I do think especially as we get more enterprise customers (currently 4 of the Fortune 10 are customers; we're aiming to get to all 10 soon!), we'll be able to make it cheaper and cheaper for indie developers (maybe one day even totally free for up to, say, 100 users, or perhaps to introduce a plan that you can build public apps with unlimited users for free).
We have considered open-coring Retool. I think there are many pros to that (as you note). But my main fear is that it would be difficult to build a business around it, since we'd be stuck selling either hosting or support (neither of which is particularly high margin; cf. Elastic). Or we'd be forced to limit the open-source version to not have important features (e.g. SSO)... and it feels like we wouldn't be true to the open-source philosophy if so.
Hi Marak! Let me know if you think this response is fair: https://news.ycombinator.com/item?id=27252331. I'd summarize it as "we used a MIT library to generate some data, and unbeknownst to us, this MIT library linked to proprietary data. We then immediately removed such data once we found out."
If you don't think that's a fair reaction, would love to hear your perspective and buy you a coffee next time I'm in NYC. I'll send you an email now. :)
Sorry I didn't link to a Dynaboard email. Here's what an (unhappy) customer of theirs sent me: https://imgur.com/a/qTGpgbQ. They were unhappy because they're a) losing all their data, and b) losing all their applications.
Hm, sorry you found us to be expensive. Two notes:
* Forms (ie the product here) is free.
* We’ve always aimed to build a sustainable business where we charge reasonable prices and can guarantee we’ll stay in business ourselves. It’s true there are other products that are cheaper, but every single one of those companies is unprofitable and many will probably be dead in a few years. See, for example, Airplane, Interval, or Dynaboard. Dynaboard just got acquired today (their founder is apparently “thrilled” about it: https://dynaboard.com/blog/figma-acquires-dynaboard) and they’re shutting down on April 30th. If you’re a paying customer you’ll need to rebuild all your apps by then. Ouch! (I’d rather pay more and not have worry about core pieces of my business getting shut down with three months’ notice.)
Agreed. I find my AVP actually quite bad for using my Mac. I use a MBP instead of a MBA because 120hz makes a big difference. The MBP screen within AVP is probably something like 30hz (likely because it's using Airplay, and it doesn't have enough bandwidth). And I can't change the resolution either! It's kind of like working on a TV — I don't see why it's any better than the 14" MBP screen.
Overall, the AVP is a disappointment for me. Most of the new UX patterns I find far worse than keyboard shortcuts. (For example, a window manager is _much_ easier to use than having to pinch to drag windows around. For example Vimium is much easier to use than looking at elements and pinching at things.) I don't consume much content (e.g. TV), but of the content that I do consume, it feels lower resolution to me. The demos they have (e.g. the Alicia Keys video) feels nothing like real-life to me. As a parallel to what you said — real life has never looked better (after taking off the AVP), haha.
I have a lot of respect for the product and the folks at Airplane. And I (even as a "competitor") find it sad that such a great product is being shut down. My best guess is that they were running out of cash.
This to me is pretty surprising... because it's actually not hard to make a SaaS business profitable. You just have to build a great product, and be disciplined at hiring. It's weird that they seem to have done well on #1, but failed at #2 (which I'd deem the "easier" problem).
RE #2, I've heard they have less than $1M in ARR, but somehow (according to LinkedIn), have 61 employees. We had 4 employees when we were at $1M in ARR (and growing around 700% YoY). Even when we were growing quickly, we hired slowly: IIRC we were at around 30 employees at around $10M ARR. (That's less than half the employees Airplane had... even though we were 10x their revenue.)
When we started Retool, average headcount costs were around $300k / year. So if you have 60 heads burning $300 / year, that's $18M / year. If you only have $1M in ARR, you're burning $17M a year. Ouch! (If you're burning $17M a year, it's not hard to see why a fundraise of $32M would only last you 18 months.)
To me, it's tragic that a great product like Airplane has to shut down. Tragic both for the team, but also for its customers (who have three months to rebuild everything). Building a great product is the hardest part of starting a startup, not "not hiring". I'm hoping that a more challenging fundraising environment will make ~profitable startups more common going forward. (Especially because it shouldn't be that hard to make a SaaS company profitable!)
My sense is that many other startups are going to be going through something similar over the next few years. For example, last I heard, another one of our competitors (with the initials SB) has less than $1M in ARR and has 40+ employees. I feel that the 2020 - 2022 fundraising environment has spawned a bunch of fairly unsustainable businesses — and many of them will shut down in the next year or two. As consumers, it would be wise for all of us to be conservative when it comes to which platforms we choose to build our infrastructure on.
Law enforcement is currently attempting to ascertain whether or not the actor is within the US. If it's within the US, I (personally) believe there's a good chance they'll take the case on and presumably with enough digging, will find the attacker. (The people involved seem to be... pretty good.)
But if they're outside US (which is actually reasonably high probability, given the brazenness of the attack, and the fact that they're leaving a lot of exhaust [e.g. IP address, phone number, browser fingerprints, etc.]), then my understanding is that law enforcement is far less interested, since it's unlikely that even an identification of the hacker would lead to any concrete results (e.g. if they were in North Korea). (FWIW, the attack was not conducted via Tor, which to me implies that the actor isn't too worried about law enforcement.)
To give you a sense, we are in an active dialogue with "professionals". This isn't a "report this to your local police station" kind of situation.
Hi, I'm sorry you felt that way. "Shifting blame to Google" is absolutely not our intention, and if you have any recommendations on how to make the blog post more clear, please do let me know. (We're happy to change it so it reads less like that.)
I do agree that we should start using hardware keys (which we started last week).
The goal of this blog post was to make clear to others that Google Authenticator (through the default onboarding flow) syncs MFA codes to the cloud. This is unexpected (hence the title, "When MFA isn't MFA"), and something we think more people should be aware of.
Hi, David, founder @ Retool here. We are currently working with law enforcement, and we believe they have corroborating evidence through audio that suggests a deepfake is likely. (Put another way, law enforcement has more evidence than just the employee's testimony.)
(I wish we could blog about this one day... maybe in a few decades, hah. Learning more about the government's surveillance capabilities has been interesting.)
I agree with you on hardware 2FA tokens. We've since ordered them and will start mandating them. The purpose of this blog post is to communicate that what is traditionally considered 2FA isn't actually 2FA if you follow the default Google flow. We're certainly not making any claims that "we are the world's most secure company"; we are just making the claim that "what appears to be MFA isn't always MFA".
For us, every single one of the logos we display on https://retool.com has a committed contract with Retool where they agreed to display their logo. (Generally our champion does need to go ask a VP; in return we offer a discount.) 100% of the logos that we show pay us more than $50k a year. (80% of them pay us more than $100k a year, and some % of them pay us more than $1M a year, hah.) We wouldn't want to display their logo otherwise! (Since it'd be misleading, but also because it'd be problematic — if say — Taco Bell engineer came and asked us who exactly is using Retool at Taco Bell.)
I've always been confused (and rather peeved) at people who refer to Retool as a low-code / no-code tool. The vast majority of our users are software engineers, and that has always been our focus. In fact, we purposely try and filter out non-engineers from signing up. They have lower conversion rates, require more support (they oftentimes ask us to teach them how to write JS), and have lower NPS.
Our target audience is the developer who doesn't believe that building a simple form (that submits a POST request) should involve: 1) installing 30 dependencies, 2) learning a new framework, 3) spending hours researching the best table library, and 4) mucking around with redux trying to figure out how to get a spinny indicator on a button.
The state of web development today is _insane_, and we want developers focusing on being productive, instead of everything listed above. (Fortunately for us, most developers agree and think that web development has gotten too complicated, especially for simple internal forms.) Developers who want to ship is our market, not "non-developers" who don't know how to code.
Perhaps we should write a blog post about this one day, hmm...
It was surprising to us (here at Retool) that visual programming has never taken off, despite countless attempts over the past few decades. (That's why we started Retool, after all.) But Visual Basic is probably the product that came closest, and that's why we wrote this homage to it. It, along with Filemaker, Hypercard, are products that we loved. And we always wished that they had flourished, since then we wouldn't have had to start Retool, hah! As Linus says (in the article):
> “For example, I personally believe that Visual Basic did more for programming than Object-Oriented Languages did,” Torvalds wrote, “yet people laugh at VB and say it's a bad language, and they've been talking about OO languages for decades. And no, Visual Basic wasn't a great language, but I think the easy DB interfaces in VB were fundamentally more important than object orientation is, for example.”
I just sent you an email. We love open source, and would love to support you in any way possible!
On public apps: we are in the process of creating a separate pricing package for that based on something other than users (e.g. pageviews). Since you're working on an open source project, we're happy to offer it to you for free; will follow up over email.
Performance is our #2 priority for our engineering team this quarter. We have made some notable gains, but there is much more work to do. Thank you for the feedback and for sticking with us; we are hard at work on it, and expect to deliver more performance wins over the next few months. (If there are tips you want on improving app performance, feel free to reach out to me; we are happy to get an engineer from our side to help debug why things are slow.)
I'm sorry; we are actively working on our pricing model right now. (We today launched a 5-seats-for-free plan: https://retool.com/blog/new-free-plan-2022/.) I think charging for end-users does make sense, but we need to think about exactly how much (as you note). Thank you for your feedback!
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.)
I do think there is more work for us to do — I do think especially as we get more enterprise customers (currently 4 of the Fortune 10 are customers; we're aiming to get to all 10 soon!), we'll be able to make it cheaper and cheaper for indie developers (maybe one day even totally free for up to, say, 100 users, or perhaps to introduce a plan that you can build public apps with unlimited users for free).
We have considered open-coring Retool. I think there are many pros to that (as you note). But my main fear is that it would be difficult to build a business around it, since we'd be stuck selling either hosting or support (neither of which is particularly high margin; cf. Elastic). Or we'd be forced to limit the open-source version to not have important features (e.g. SSO)... and it feels like we wouldn't be true to the open-source philosophy if so.
Thank you for considering Retool!