Thank you! We spent a lot of time with the demos on the home page, the essays page, and upgrading the docs.
We're going to redesign the dashboard in the next few weeks.
One interesting observation from our users: though they use the dashboard less in some ways (the AI agents spin up apps and make schema changes for them), we found people use them _more_ in other ways. Instant comes with an Explorer component, which lets you query your data. We found users want to engage with that a lot more.
Add a list of people (PMs) who have added feature requests. Have their username be "<username> (<Full Name>) - <karma points>" and then I can click through to see their bio.
Genie 3 is super impressive -- but you can't manipulate it programmatically like Minecraft.
We've built our infra so that we can plug in any simulation environment. If an AI-generated world starts being programmatically modifiable (and has really solid object permanance :) then we'd happily use it!
Minecraft has a DSL that lets you manipulate the world. We've piggy-backed on that, along with a K8s infra to run N worlds in parallel, to let you create simulations of arbitrary complexity.
We think simulations are the best way to test frontier AIs due to their degrees of freedom and expressivity.
I built an app (HN Clone, of course) with Instant's MCP hooked up to Claude Code.
The experience was brilliant.
Pros:
+ Fast
+ Easy
+ "Vibe coding on steroids" basically
+ The sense of 'wow' that comes very rarely with new tech
Cons:
- It used Instant as the database/backend, but I wasn't sure what it had done / how exactly it worked and had to spend a bunch of time asking Claude + reading the code to get it. It seemed reasonable, but if I were doing a prod system vs a PoC, this is where the time would be spent. ("Vibe coding lets you create tech debt 10x faster")
Net-net: This is the way for prototyping / validating. This is probably the way for production systems in N months too once the toolchain + agents get better.
Would you mind sharing the code, as well as prompts if you're comfortable? I'm trying to sample anecdata to help re-baseline my intuition on these things.
* Be careful when sharing log files. Claude can include secrets in there. Some hackers may notice an adminToken in the convo. I rotated it before we pushed.
* It was fun to see Claude use the query language. It thought we had a `$startsWith` modifier. Right now we only have $like. But `$startsWith` is a great idea, we may just implement it real quick!
> It thought we had a `$startsWith` modifier. Right now we only have $like. But `$startsWith` is a great idea, we may just implement it real quick!
Haha, that's great. Turns out that "hallucinations" are just things that make sense in context, and that can translate to feature requests from our agents :)
[Firebase founder] The thing I'm excited about w/Instant is the quad-fecta of offline + real-time + relational queries + open source. The amount of requests we had for relational queries was off-the-charts (and is a hard engineering problem), and, while the Firebase clients are OSS, I failed to open source a reference backend (a longer story).
I always assumed that an architectural decision had prevented relational queries in Firebase.
It was jarring to find out that indexes are required for every combination of filters your app applies, but then you quickly realize that Firebase solves a particular problem and you're attempted to shoehorn into a problem-space better solved by something like Supabase.
> I always assumed that an architectural decision had prevented relational queries in Firebase.
Seems the biggest problem is that Firebase doesn't have relations. How can you query that which does not exist?
I'm guessing what they really want is SQL? Once upon a time when I was stuck on a Firebase project I built a SQL (subset) engine for Firebase to gain that myself, so I expect that is it.
Why not? You're asking a question, of sorts, and getting an answer from the result. That's the literal definition of querying.
> Grabbing all the docs in the db into my controller and filtering down that array is what Firebase makes me do instead of writing queries.
A query language is just an abstraction. One you can have in your code. At some point you still need to "grab all the docs into a controller and filter them down", though. You could push that step into the Firebase service, but it would still have to do the same thing you're doing. There is no magic.
Better would be to provide something indexable so that you don't have to go through all the docs, but you can't index that which does not exist.
How hard is it to swap our firebase for instant? I've had an amazing time with firebase, but I sorta want to switch to using a completely local solution.
I have a small lyric video generator, and while I don't care about my own songs potentially leaking, I would never want to take responsibility for something else's data. I basically use firebase for the lyrics afterwards I transcribe them .
Second, do you offer your own auth or just integrate with other solutions.
> How hard is it to swap our firebase for instant? I've had an amazing time with firebase, but I sorta want to switch to using a completely local solution.
It should be relatively straightforward to switch. If you have any questions, you could always reach to us on Discord [1]
The only caveat though: Instant is like Firebase; it is not a completely local solution. If you are worried about exposing some data over the internet, I would store the same kind of stuff you were thinking about with Firebase.
> Second, do you offer your own auth or just integrate with other solutions.
We offer our own auth. You have magic code emails and Google Sign in out of the box. We also expose auth functions in admin SDK, in case you want to create a custom solution. [2]
I'm actually imagining telling end users to host the server locally via Docker. I have some other functionality, like the actual lyric transcription, I need docker for.
Thank you for your help. I'll definitely look into this for my next project
> Instant is like Firebase; it is not a completely local solution. If you are worried about exposing some data over the internet, I would store the same kind of stuff you were thinking about with Firebase.
What does this mean exactly? If you host your own it is still not local?
Side point: television is a bastard word, but erogenous is not Greek eros + Latin genus; it's all greek (ἐρωτογενής — it would be erotogenous in English since the root of the word eros is erot- , but the extra syllable was dropped; another example of differentiated transliteration is φωτογενής which became photogenic instead of photogenous).
I have just written an essay about the word water in the sibling post comments.
One thing I discovered in the process is that the word water comes to english all the way from Proto Indo European. The word hydro, however, comes from ancient greek, which comes from the same PIE word for water.
You probably heard this a million times but I still remember trying that simple firebase demo of draw in one box; see the results in another and being amazed. That was one of my pushes out of boring enterprise software death by configuration and into software creation based on modern OSS products.
Seeing traces in real-time (and Claude seeing them too) is so so good. The velocity speed up is hard to understate.
Request for the Raindrop team: I wish your eval support was better. It’s not great having it completely disconnected from my CI system.
reply