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.)
As a counterpoint--from another potential user who looked at Retool first but landed on a competitor's product because Retool was too expensive--another way for me to avoid that outcome is to choose a tool that's open source and self-hosted. That's precisely what we did. If/when the company goes out of business, we can keep using it; this already happened to us with RethinkDB and we continue to run that in its community-maintained form. I'll likely want to find a new platform for new development but I won't have to rewrite my existing apps by a deadline.
You're right that it's a big concern, but it's a pretty tough sell to solve this problem by just charging so much that it's clear you could not possibly go out of business. I had to go pretty far down the list of your top competitors to find a good one that was open source, but I did find it.
All that said, Retool's pricing at that time was MUCH worse than it is today. This is what Retool was offering us at the time: https://web.archive.org/web/20230315060042/https://retool.co... -- no distinction between developers and end users! No access controls until the $50/user/month level! That was totally out of the question. The current pricing looks a bit more reasonable, but it's too late; we already committed to the competitor offering an open source solution.
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.
As someone who also tried and really liked Retool but also found it too expensive I can add my reasoning.
I help companies with digital transformation, what it usually entails is deploying solutions to small teams and then growing them as we get buy in from the business. The initial users are high frequency users of the tools, and later users might be infrequent users.
The problem I found with Retool was that as I scaled to the infrequent users the cost per user remained static, so I would be punished for my tool becoming more popular.
Dynaboard shutting down does not relate to pricing for end-users.
From a Low Code product perspective, we were still able to build a beautiful and functional product. Our product unit/engineer ratio is much higher than our competition (see, for example, Retool), which allows us to provide the best value for our users. Regarding the transition, I don't see any indication from the note you posted that users will have to rebuild all their apps. Rather, the founder is saying he will provide more information and possible steps. Who knows – maybe it would be integrated into Figma? And Figma would gain great runtime and IDE capacities?
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.
mehal and I are former Dynaboard engineers, so we are well aware of the situation. No one is more upset about the removal of Dynaboard than the team, but it doesn't justify poor pricing practices from competitors
Just wanted to echo I love your product but the pricing is too prohibitive. My use-case is wanting to offer a dashboard to my own clients. But the business pricing was $50/mo per user and also gave each user editor privileges.
I want to create customer accounts, apply settings (e.g. I delimit the data their account can access, basically adding WHERE clauses on a per-account basis), and they can access white-label read-only dashboards with their own user/pass.
Retool seemed 100% insistent on being an internal-only tool with a high cost per user.
Hi! Last year, Retool introduced differentiated pricing for end users (viewers) and standard users (editors) to make these kinds of use cases much more palatable[0]. We also rolled out support for building customer-facing apps through letting you whitelabel and ship apps to people outside your organization [1].
Would be more than happy to talk through your use case; feel free to reach out at antony[at]retool[dot]com.
Pricing is always tricky. One pricing never fits all use case. So we have worked hard to offer pricing options like usage based pricing/ dev based pricing in addition to user based pricing.
Was curious to apply your use case and see if our pricing model maximises ROI.
Disclaimer: I am co-founder at a retool alternative platform for building internal tools and enterprise apps.
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. :)
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.
You can change the resolution though? If you go to Displays on your mac you can change the resolution of the AVP mirroring. I find it works much better at "1080p" than the default since it makes small text much more readable.
You can combine paradigms for the best of both worlds (e.g. physical keyboard + your apps). I imagine that IDE experiences will only improve as time goes on.
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.
I think the Airplane Linkedin is overrun by people who say they work on an Airplane (the word not the company) :) It looks like they only had ~20 employees so not a super large team.
I completely echo the sentiment of being frugal. (We are a competition to both retool and airplane and bootstrapped)
One of the companies we sold earlier was around leadership learning content and I was attending one shoot where the CEO of india unilever business was recollecting lessons from professor Ram Charan. one of them broadly equated inverse relationship between aspiration and resource as a determinant of entrepreneurial mindset. And they at unilever used to artificially starve resources to create such an environment for out of the box thinking. Net net there mostly exists a way to achieve things with minimum resources. And tough markets calls for such measures even more.
Another competitor of Retool with around 150 employees is very far away from 1m in revenue as far as I know. They recently did a layoff as well. VC money that flowed in 2021 has created a bunch a money burning machines.
Our startup evaluated Airtable, Retool, and Airplane, and settled on Airplane. We liked the Airplane because it's developer-friendly. But the way they throw all customers under the bus is sad.
Hope the acquisition works out. I used to work for FileMaker, and from the business perspective, their products are complementary to each other.
we'd love to make the migration as easy as possible and would definitely be open to building an import tool. In the meantime if you're migrating feel free to email me at jamie at retool.com and I'd be happy to help import
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.
I felt like you were trying to shift blame to Google due to the title "When MFA isn't MFA" and your emphasis on "dark patterns" which, to be honest, I don't think they are that "dark". To me it was because this felt like a mix of a post mortem/apology, but with some "But if it weren't for Google's dang dark patterns..." excuse thrown in.
FWIW, nearly every TOTP authenticator app I'm aware of supports some type of seed backup (e.g. Authy has a separate "backup password"). I actually like Google's solution here as long as the Workspace accounts are protected with a hardware key.
The only real lesson here is that you should have been using hardware keys.
This comment reads more poorly to me than the actual blog post. It _should_ be your intention to shift partial blame to Google, and you should own it. It's ridiculous that they make an operation like syncing your MFA keys seem so innocuous. I just changed phones, so I'm just seeing this user flow for the first time, and it is ghastly how they've made it the default path.
Changing things to make it less offensive to someone who was offended really waters down your position.
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".
Thanks for all this insight, this is why HN rules. What is your impression of law enforcement, everyone claims to reach out after an attack, but I've never seen follow up of sucessful law enforcement activity resulting in arrests or prosecution. Thanks again.
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.
FWIW engaging simultaneously with both the FBI and the USAO/DOJ and putting pressure on DOJ to act on the case typically results in better outcomes than just assuming the SA assigned is going to follow through and bugging them about it.
Most attacks like this use stolen credentials for VOIP providers, i.e. Twilio. It's likely the FBI quickly obtained a subpoena which produced a recording. The attacker may not have known the call was being recorded.
This is an example of Google sabotaging a techology it doesn't like. I'm not saying it is a conspiracy. But by thwarting TOTP like this, Google is benefiting.
I really like TOTP. It gives me more flexibility to control keys on my end. And you can still use a Yubikey to secure your private TOTP key. But you can also choose to copy your private key to multiple hardware tokens without needing anyone's permission. Properly used, you can get most of the benefit of FIDO2 with a lot more flexibility.
I actually recently deployed TOTP, and everyone was quite happy with it. But knowing that Google is syncing private keys around by default, I no longer think we can trust it.
Since you might have you delete the reply anyway, can I get a candid answer on why hardware 2FA tokens weren't a part of the default workflow before the incident? Was it concerns about the cost, the recovery modes, or was it just the trust in the existing approach?
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.)
that's awesome. Just a thought, I wonder if users would appreciate knowing that. To me, the reason I asked is I tend to assume the worst (minimal permission, 1 person in the org, no contract, etc...). Maybe just me, but especially so when it's huge names like Amazon or Stripe
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...
* 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.)