dvdhsu

I work at Retool, and probably the majority of our business today is "replacing SaaS with citizen-developed apps". I think that a lot of these CRUD-y SaaS products (which is, really, what BI is) will disappear over the next few years. The bottlenecks I see:

* Data quality — we've seen Databricks / Snowflake schemas with 10^5 tables. Just putting a LLM on that doesn't work - you do need some sort of semantic layer. This is especially bad since LLMs are like slop cannons — if you ask it to prove X with the data, it will build you an app / visualization that proves X.

* Deduplication — it turns out many people want moderately different views of the same data. How can you host everything centrally and DRY everything out such that you can guarantee correctness?

* Writing data back — this is where it gets really hairy. Dashboards that only read data from Databricks is dangerous insofar that data can leak. But once you start needing to write data back, you need access to APIs / MCPs... and then you want some sort of authorization layer (since many SaaS apps don't have great authorization within themselves).

Obviously we work on quite a bit of this at Retool, but we are always looking for ideas on how to make this better. We believe that many things should be in a platform (e.g. centralized data connectivity, authentication, authorization, etc.) setup by engineering, and then non-developers can go crazy generating safe apps.

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 frankly, quite 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 possibly 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!

Hi all, founder @ Retool here. We initially launched Retool on HN five years ago: https://news.ycombinator.com/item?id=14515494. The feedback was extraordinarily helpful then (e.g. we launched source control, on-prem, etc. based on HN comments), and we’re grateful for all of it.

Today, we’re excited to get HN’s thoughts on one of our new products: Retool Mobile. It lets you build and deploy mobile apps in minutes, not days. The idea is there is a large class of line-of-business mobile apps, and the process of getting a simple form + button on a mobile device, in a native app, to POST back to an API endpoint, is startlingly difficult. (As a web developer myself, it has for a while been shocking how hard it is to build and ship something useful onto the app store.)

For us, it was important that we build a native mobile app. That’s because although the web as a platform has come a long way, we think Apple / Google are — to some extent — anti-web, in the sense that they hamstring web developers in an attempt to get more apps on their app stores. With a native app, we were able to ship a brand new set of mobile-specific components, drive substantially more performance, and frankly — deliver much more delight.

The team is currently hard at work on white labeling, offline apps, and push notifications. We expect to ship all that in the next few months.

If you have any feedback on the product, please do comment in this thread! HN is a particularly valuable source of product feedback for us, and the team is very eager to please HN readers. (Since if we can do that, we can surely please any developer, hah!)

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