dvdhsu

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

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!

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.

(So yes, I suppose the comment was tongue in cheek, haha.)

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.

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