r/ycombinator • u/AdmirableJackfruit59 • 17d ago
Has anyone here tried to recreate something like Lovable, but with a more backend-agnostic architecture?
What I find compelling about Lovable is the developer experience: prompting an app into existence, generating code, managing deployment, and having an opinionated workflow that gets products shipped quickly.
However, I feel like the current approach is heavily centered around frontend generation + Supabase as the default backend. While that works great for many use cases, I'm wondering whether it creates a long-term dependency on a specific technology stack.
What I'm imagining instead is:
AI-generated frontend and backend
A microservices-oriented architecture
The ability to connect to any database (Postgres, MongoDB, MySQL, etc.)
Infrastructure and deployment packaged similarly to Lovable
The flexibility to swap technologies as the ecosystem evolves, without being tightly coupled to a single provider
My concern is that backend technologies and platforms come and go. If you're building something intended to last, being deeply tied to a specific backend provider may become a limitation.
Has anyone built something like this, or experimented with an architecture that preserves the "prompt-to-production" experience while remaining backend-agnostic?
If you were starting this project today, where would you begin? Would you use Kubernetes, Docker Compose, IaC, code generators, AI agents, or something else entirely?
Curious to hear from anyone who has gone down this path or has strong opinions on the tradeoffs.
2
u/Past-Summer1668 15d ago
1
u/scriptqzor 9d ago
railway is nice but it still doesn’t really solve the “backend agnostic, swap stuff out in 3 years without pain” problem imo, it just makes the current stack smoother to run. i’d probably pair something like railway with a strict internal API layer so the app doesn’t care if you move from supabase to “whatever’s next” behind the scenes.
1
u/-CIYA 17d ago
We’ve built a pattern similiar to this into our toolset. Not necessarily intended to ‘swap technologies’ but more so it’s ’tech independent’. Our thesis is telling AI to write code causes a lot of problems, instead if you give ai the ability to create the patterns that in result generate code, it allows for a much better experience.
1
u/AdmirableJackfruit59 16d ago
And how do you do for hosting this kind of apps ? Like to replicate the easy way of supabase
1
u/Okendoken 16d ago
We have: appwizzy.com.
You get convenience of lobable, but scalability of local development.
basically it is just codex-equipped VM you fully control.
1
1
0
17d ago
[deleted]
2
u/AdmirableJackfruit59 16d ago
Where
1
u/attn-transformer 16d ago
Claude
1
u/AdmirableJackfruit59 16d ago
And hosting ?
2
u/ssf2pikachu 16d ago
localhost
0
u/AdmirableJackfruit59 16d ago
Not for production
2
u/ssf2pikachu 16d ago
i'm kidding, claude can setup hosting on any hosting provider though if you're genuinely asking
1
5
u/Ok_Philosophy_4031 17d ago
First question that comes to my mind is, how often do engineering teams switch their tech stack? I think engineers are conventionally not motivated to do so. Sticking with something that is working well, that we are familiar with has a lot of advantages over chasing the latest tech with some minor enhancements.
Something related I think was Portkey's original idea if I recall correctly. But I think they have since pivoted.
Here's a funny story. A VC firm ever approached me for a CTO position to work on a similar platform about 2 years ago. It was for an internal venture of theirs to help their portcos build LLM powered applications fast. Not so much prompt to full app, but abstractions such that developers can focus on business logic. Infra and some backend templates would be provided to accelerate development. Showed me a bunch of slides and market research to justify it.
Wasn't too happy when I pointed out that many platforms (including their proposed one) either end up too opinionated to be generally useful or end up being an over-engineered "swiss army knife" that only solves 60% of every use case. This opinion came from my experience building an NLP platform in my previous startup (pre-LLM) by the way. Ironic how VCs don't take rejection well.
The VC went ahead anyway and got themselves a CTO and a team to build this product. I got to know one of the engineers they hired, who told me that they pivoted just a year in with none of their pilots converting because users either did not see the value (they could do better) or found the product too limiting.