P.S.

We're just a team of two engineers building our first public startup after work. We appreciate your feed and support! Thank you!

And I've just published tutorial how to build fullstack app out of one SDK method call.

rushdb.com/blog/backend...

Building a SaaS? Easy.
Catalog with filters? Done. Out of the box.
RAG app with vector search? Supported
AI workflow with flaky LLM outputs? RushDB got you.
RushDB speaks your language - without forcing one on you.

No schemas (if you want to), no config.

Just push. And build.

And this is how rushdb.com emerged. I've built it to address every builder and indie hacker pain: eliminate data rituals completely.

→ Push any JSON
→ It parsed instantly to "property-graph"
→ Data is queryable now
→ Parent-child relationships auto-created

Here's more:

Good UX for this kind of apps should provide a great filtering and search. And the only way to achieve that at scale on any incoming (undetermined) data - is to build "property-graph" on the fly.

For reasons, I wasn't able to market this app. But I succeed at the architecture.

But before, a short story. 7y ago I wanted to build b2c app for collectors: vinyl, art, beercaps - you name it. Nothing in common. People want to organize their collections their own way and describe items without fake-flexible templates. And this is the most challenging part:

Thanks to vibe coding era, we can now entertain ourselves with watching how LLMs fighting with Supabase and (sometimes) wins.

But complexity isn't gone. It's just delegated.

This is why I've all-in into developing absolutely different approach:

→ Define schemas & migrations
→ Write models, controllers, services
→ Build and wire a REST API
→ Normalize data by hand
→ Sync with the frontend

Weeks after - you finally can save submit form from UI and have a rest.

But should it be like that?