jag729

In the same boat. Tried Notion Mail and it wasn't quite at Superhuman's level, though I do anticipate they'll improve it.

In the limit, though, are these things real roadblocks to app builders replacing SaaS? Paying for reliability/support seems like the only real remaining advantage of SaaS if codegen models get 3-5x better, and even then the bar is the reliability of SaaS apps right now (which in a lot of cases is not that high).

Could imagine a single universal app builder just charging a platform fee for support, or some business model along those lines. (Again, in the limit, I'm not sure that support would be too necessary)

Ha, might be more effective to have to say some long passage; could see myself eventually saying "I'm a loser" habitually to access the sites without internalizing the meaning.

actually I think this is a limitation of ArXiv -- clicking on the principal author links to a search for "K Huang," (which is a super common name). Limiting to the author's actual name only produces 6 results.

interesting -- I found it through recent submissions, so I'd be leery

I used Framer for this; I’m not too sure where the trend for this particular style started, but my guess is Cursor’s landing page (unless they were in turn emulating someone else)

Oh weird, let me take a look at that

We do use the privacy APIs (when available) for requests, but we also extract schemas + data points from each silo for PII scanning and data mapping.

out of curiosity, what OSS alternatives do you have in mind for the OpenAI/Pinecone dependencies?

Exciting to see a launch in infra access -- seems like there's a great team behind it, too. Congrats!

Thank you!

You're right; distribution is one of the biggest challenges for a service like this. There's a bit of a tradeoff in my eyes; you can either support a few setups with seamless self-service, or you can support everyone but on a case-by-case basis. We think that the IaC approach bridges the two; our goal at the moment isn't to rush to fully hands-free self-service, but rather to optimize for the range of configurations we're compatible with and how seamlessly we can support clients on those stacks.

Using IaC helps a lot with the former, and getting experience onboarding different clients has helped with the latter - we're now familiar with common hangups (e.g. figuring out the data layer), and we've built processes into the product to get around those (e.g. immediately populating a test DB from a specified staging DB). We've seen progress in how quickly we can get people onto the platform; it now generally only takes a day, and we're bringing full self-service in sight as that duration decreases.

That being said, our broader goal is to hit the larger enterprise market, for which (as you mentioned) a higher-touch approach is warranted.

Absolutely - managing and syncing the state of IaC tools is core to the value of Gallery. Infrastructure templates can be edited without changing currently-active environments, and this is handled gracefully right now. Propagating template updates to running environments seamlessly is also on our roadmap.

Thanks for your feedback! We've weighed these considerations quite a bit in choosing the right first step for the product.

The docker-compose approach is a valid angle — we’ve seen a couple products built around that workflow. A weakness that led us to our approach is that they generally lack support for projects that involve cloud-specific services. Most of the startups we’ve talked to already have some infra-as-code that describes their cloud infrastructure, and we’re rolling out support for CloudFormation/Pulumi very soon, so customers will be able to bring over infrastructure in any major format. As far as limiting the breadth of services spun up, we've found that removing unnecessary services from the IaC config provides reasonably good results. We plan on adding support for a Docker-compose approach soon, but we felt that starting with IaC would bring us better generalizability out of the gate.

We have reverse terraform support for some services (for example Cloud Run, multiple firebase services, etc.), where we automatically generate the Terraform (if you use services that are not supported, we do offer to manually create the terraform infrastructure as part of the onboarding process).

The reason we have a read-only demo is because of the friction required to set up an account (you have to link your cloud account and repositories); we felt that the read-only account was the easiest way to take a look at the features without needing to go through the account creation process.