dvdhsu

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.

Thank you for considering Retool!

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.)

Amazon pays us more than $1M annually. See also: https://news.ycombinator.com/item?id=37426191

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.

Sorry, forgot to write the footnote so just removed it. Agreed that building a great product and finding PMF is hard. But "not hiring" shouldn't be!

(So yes, I suppose the comment was tongue in cheek, 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.

(May also have to delete this later, but...)

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.

It is not based on the sole testimony of the employee. (Sorry I can't go into more details.)

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".

(I may have to delete this comment in a bit...)

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.)

(Founder at Retool here.)

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...

(David, founder @ Retool here.)

Hi Taylor! (David here, CEO @ Retool.) I've reached out over email; this sounds like a bug on our end. We will fix it. Thanks for using Retool!

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.”

(Founder @ Retool here.)

Haha, as an HN reader, agreed that it comes across that way. We haven't (and will not) astroturf. I'm guessing this particular user here is John Hughes (https://www.linkedin.com/in/john-hughes-628713227), who works at a company called The Modern Milkman (https://www.modernmilkman.com/home/). Here's a recent video of him talking about how he uses another Retool product, Retool Workflows: https://youtu.be/a8lVEYiUJdc?t=2681.

John has no financial interest in Retool. But I am glad that he likes the product!

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.)

Ah, we still have a way of generating mock APIs: https://retool.com/api-generator. You can upload a CSV (we'll parse the columns and guess types for each one), and then generate mock data and put it into an AIP for you: https://retool.com/utilities/generate-api-from-csv.

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.

Yes, this is something our infra team is working on right now. As of today, somebody in Australia, with a database hosted in Australia, experiences two round-trips in order to get data (client => our backend => database => our backend => client). We are working on deploying our database connector in far more regions so this won't be a problem. I think ETA is ~next two months? Will check in with team now...

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.

We probably should support that. What's happened is we initially built the feature for an on-prem customer and never bother supporting that for the cloud version (since anybody who wanted it would just use the on-prem version). Let me follow up with the team now and see how much work it would be to bring it to cloud. Thank you for the feedback!

We actually didn't need the money (we're cashflow-positive). In fact, we haven't touched the money from our Series B (in 2020) nor our Series C (in 2021). But raising money is helpful because a) it gets prospective customers interested in the product (oh, X company raised, let me check out what their product does), b) it gets prospective employees interested, c) it allows people externally to see that the company is making progress rapidly (I wish we could post revenue metrics here, but I... think that's a bad idea?), and d) we sold very little in this round (1.4%, so there is minimal dilution to employees), for those advantages.

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. :)

Metabase is great! I was using it 4 - 5 years ago and it was shocking how good it was as OSS.

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).

Yes, that is our target market too. We don't think people will be building airbnb.com (say) in Retool, but not all software is like that. (In fact, we think most software is probably just CRUD apps, haha.)

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.

Hi all, founder @ Retool here. We've made a lot of progress over the past few years, but we first started on HN, and certainly wouldn't be here without all of you!

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...

Hi speedgoose; I'm founder @ Retool. I'm sorry you were priced out of Retool; we don't want anybody to be that way. We're trying a few pricing experiments now (including self-serve on-prem, not billing per-user, etc.). I tried shooting you an email to a) fix the issue, and b) gather some feedback, but I don't think you have an email listed. Do you mind reaching out to me at david AT retool? Thanks!

When Marak sent me the email, I read it as a "Hi, I built Faker, might you be interested in acquiring it?". I responded with a "yes, that could be interesting, give me a day to work on this". In the end, we decided that acquiring Faker didn't make sense, and I'm sorry to Marak for not sending a follow-up email telling him we weren't interested. In this case, the content is different (i.e. we are potentially abusing OSS), which is why I’m responding to this.

(FWIW, I typically receive 50 - 100 sales emails every day. I do try and reply to the ones that look interesting, but I do forget to follow-up sometimes if we're not interested! This does not excuse my behavior in this particular case, and I’m sorry to Marak for not following up.)

Hi all! I'm David, CEO @ Retool. I'm looking in to this right now and will update my comment here with a response in the next two hours.

Edit: just did a bit of digging.

It looks like we have a Retool template that has some fake data in it (https://retool.com/api-generator/). This is an app built in Retool, and has a few thousand rows of hard-coded data.

Most of this fake data is self-generated, but we used the faker.js library (https://github.com/marak/Faker.js/) to generate three datatypes: IP address, avatar, and industry. This MIT licensed library, when used, creates data that links directly to fakercloud (https://cdn.fakercloud.com/avatars/). Here is the code itself: https://github.com/Marak/faker.js/blob/master/lib/internet.j..., and here is a demo that shows the library generating those links: https://rawgit.com/Marak/faker.js/master/examples/browser/in....

I just spoke to the engineers who worked on this project, and we are sorry for including links to fakercloud. This wasn’t intentional, and we just pushed a commit removing all avatars from the template. This is already deployed. I hope you all can understand why we trusted the data generated by the MIT licensed project, and didn’t think it would link to anything proprietary.

I myself am an engineer (and avid HN reader, as evinced by how I found this while reading HN on a Sat night), understand Marak’s frustration, and agree that monetizing OSS is hard. While we’ve already contributed around $10k to various libraries we use (https://opencollective.com/retool), including faker.js, Babel, ESLint, and JSON Schema, I’m going to see if there is more we can do. We’ll be writing a blog post about it this week and I will follow up with more next steps. I wonder whether there is a better way of sponsoring OSS, other than just donating dollars every month? (Maybe we could commit one engineering-day per month for contributing back to OSS libraries we use heavily?) In the meantime, we'll certainly continue sponsoring all the libraries we’re sponsoring already, including faker.js.

(Also: I’m sorry to Marak for not responding to his email re. acquiring Faker. More in this child thread: https://news.ycombinator.com/item?id=27252420)