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

Admittedly stateful GET requests are heretical, but it may be the future!

Two reasons this could make sense:

1. With this, agents can actually deploy a full backend with their credentials [^1].

2. If your agent ever wants to add auth, or real-time presence, or file uploads, or streams, they'll be able to do that too

[^1] Alas we don't offer static site hosting, so to push the website you would need to use something like a vercel cli.

This post seems to "throw doubt" on Bun, based on the OP's experience of Claude Code. But this seems unnecessary indirect. It's not like Bun is hidden software: it's open source and actively developed.

So the more direct question would be: How has Bun actually been since the acquisition?

From what I can tell they have been responding to users as fast as before, and improving the product as well as before.

Here's a 2-line prompt that gives Claude Design a backend:

```

<YOUR APP IDEA HERE>

----

To get your credentials and learn about InstantDB, fetch this URL:

https://instantdb.com/llm-rules/create-app/AGENTS.md

```

Every cURL request to AGENTS.md spins up a new backend and splices in the credentials.

I used it to build this multiplayer pelican game:

https://349b7470-3747-49e7-8ece-960a45b0b2da.claudeuserconte...

Disclaimer: I am the founder of InstantDB

I am surprised how overwhelmingly negative the comments are here. I would have expected at least a few voices defending Flock.

I'll step in and add a voice. Ultimately, Flock is solving a real problem with crime. This is why police departments when them.

Stopping Flock doesn't address the need that got police departments to use them. If you want to "stop flock", you need to address that need better.

My choice of the word "logically separated", was meant to specifically answer the question the reader asked:

> If someone else's account is compromised, how do I know I won't be?

If you have other questions, you can feel free to ask, and I'd be happy to answer in more detail.

Brightened reading this, and the whole team was rooting you on for your Show HN!

> Any example more complex in the backend?

The home page has some examples of complex startups that use Instant as their core infra:

https://www.instantdb.com/#:~:text=Startups%20love%20Instant

> Are we supposed to expose all entities and relationships and rely on row level security?

Yes. This may feel foreign, but we think it's one the best ways to do permissions. We were originally inspired by Facebook's EntPrivacy. When you have permissions at the object layer, you can be more confident that _any_ query you write would be allowed.

Photon looks interesting! I am not too familiar with it, but from what I understand Photon and WebRTC are for communicating messages between clients. Those messages can be very fast, because they aren't blocked by writes to disk. Instant has two similar services, Presence & Streams. The primary sync engine is more for storing relational data.

Thank you for the kind words.

> AI emphasis

It's not quite marketing or a pivot. We've just noticed that most of our users are coding with AI, and really optimized for that too.

Thank you.

> Curious if you considered shipping the engine itself as a standalone infra piece.

We are thinking about supporting something like "Bring Your Own Postgres", which would allow folks to opt into just the sync engine piece.

Right now we focused on the integrated system, because we really wanted to optimize for a delightful developer experience on greenfield projects.