stopachka

We take our trust in our users seriously. This is why existing apps are supported until August 31st, 2027 (1 year, 10 days away). Backups will stay available until August 31st, 2028 (2 years). The product is full open source, and we put a lot of work in making it easy to self-host.

August 31st, 2027 is 1 year and 10 days away.

Re-read and it reads a lot better, good work!

This is an exciting project! My main feedback: you can definitely tell the website content is AI-generated. It's okay to vibe code the design, but I really hesitate when I see vibed writing.

Nice! Would love a brief explanation of the infrastructure. I see the Powered by "Upstash Redish Search", but why choose Upstash Redis Search vs something else?

Interesting idea! Question:

> It is highly unlikely that an AI agent startup becomes wealthy by creating the best harness for a particular use case.

If it's not the harness, what do you think is the thing that will differentiate AI agent startups? Is it mainly data, or something else?

It’s interesting that Claude chose to hint, rather than reveal the full truth or to lie.

I wonder what in the training / system prompt causes Claude to do this.

I don't quite understand, what would 100K buy you?

AFAIK you would get about ~5 concurrent users, with a max context window of ~128K tokens on the larger models.

This wouldn't be good enough for coding -- are you guys thinking of using it for something else?

Instant gives you a database, but it also gives you a sync engine that you can use in the frontend. We included this instruction because you would ideally use this to build an app.

Currently we recommend folks to write a script with the admin sdk. Efficient import / export is on the roadmap!

The UUID doesn’t actually affect the response. Every GET request still generates unique credentials each time, no matter what the value is that passes to /provision/<uuid>

We added it to help the app builders that do a lot of caching get unique responses. Turns out even if you set no-store cache headers, some app builders cache the pages. We tested this idea with those app builders and saw that they did generate uuids each time.

> Is this the kind of use case that is seen as valuable?

I think it could be. Consider an argument like this:

It's valuable to ask ChatGPT questions and receive text responses. Some of the responses are more valuable when they don't just return text, but some markup: bolding, adding visualizations etc. Why can't some responses be more valuable if they return little apps?

One place where I've wanted this myself are with using LLMs for long-running goals I have. For example, I do my blood work about once a year, and I use the results to make changes and track. For a long time I had a long chat thread with ChatGPT. Now I have a little app instead.

An extreme version of this starts to turn responses into more and more fully-fledged apps. I did an experiment recently with creating a personal finance app. I found customizing the app to my specific needs made it much more valuable to me then generic personal finance apps, which have much more effort put it, but aren't tailored to my needs [^1]

[^1]: more on this experiment here: https://x.com/stopachka/status/2040982623636607009

Oi! Updated. Should be live in a few minutes, but here's the PR: https://github.com/instantdb/instant/pull/2642

One place where a tool like GETadb can be helpful, is when you as a developer wanted to build a quick demonstration. For example one of co-founders Joe saw a tweet about how VCs were ranked. He pointed Instant to an agent, made a quick polling app, and got 600 votes [1].

We hope delightful experiences like that then prod hackers to dive deeper and use Instant for startups.

[1] https://x.com/JoeAverbukh/status/2028544576206860697

Good question. Two ways:

1. For the users table specifically, we have a default rule that says `"view": "auth.id == data.id"`. This way even if the the user (or AI) did not set access controls, user data is protected by default.

2. In the instructions file given to the agent (https://www.getadb.com/provision/new), we specifically mention permissions and how to push them. We found this prods the agent to push perms.

Here's my argument:

In practice many GET requests don't adhere to this spec. For example, when you load a page, your "view" generally changes lots of things on the backend. Those changes come back to you in ways too: for example, consider view counts on Youtube videos or X posts.

Ah, good point. We can't change the title now though.

Most LLMs in practice already read URLs. If you ask them a question they don't know, they will search and read pages.

Thank you! Yeah, it is surprising how magic words can impact the performance of LLMs