The Architecture Behind Lovable and Bolt | Hacker News Reader

The Architecture Behind Lovable and Bolt

beam.cloud

73 pointsMernit29 comments

Q: Has anyone on HN built anything meaningful with Lovable/Bolt? Something that works as intended?

I’ve tried several proof of concepts with Bolt and every time just get into a doom loop where there is a cycle of breakage, each ‘fix’ resurrecting a previous ‘break’

I too have tried them and would like to know this.

I recently played a little story based game that was hosted on Lovable. It worked reasonably well!

It depends how you define meaningful.

I built a daily newsletter with myself as the only recipient using v0. It hits the Gemini API and returns a short story based on a historical event from that day in the language(s) that I'm learning, along with a translation, transliteration where applicable, vocabulary list from the story, and grammar tips.

I've had work in the past where I spent way too long building email templates, so having that all done for me, along with the script for sending the mail, was useful. It took an afternoon project that I probably would have abandoned, into an hour project.

With that said, I'm pretty bearish on these platforms, because I think you can't build anything beyond a toy like that. And for toys or short scripts, Claude, Gemini, ChatGPT are usually good enough.

was quite impressed after building my label maker application [1] and stylex playground [2]. Had some real world needs and both were built in bolt with 99% of edits made through prompts. My tips would mostly center around:

- don't try to fix mistakes, revert and try with an updated prompt. the context seems to get polluted otherwise.

- don't treat it as a black box, inspect the generated code and prompt to write specific abstractions. don't just tell it what to build, but also how. this is where experienced programmers will get way more mileage.

[1] https://courageous-toffee-e5dd6f.netlify.app/

[2] https://venerable-melomakarona-255f96.netlify.app/

I had a trip with my family and used v0 to create an itinerary app with a timeline view of our flights, hotel/airbnb bookings, activities, etc.

It was the only thing I’ve 100% vibe-coded without writing a line of code myself. It worked pretty well. In an earlier era I might have used a shared google doc but this was definitely a better experience.

If you’re looking for things to use lovable/bolt for, I’d say don’t use it for software you otherwise would have written by hand; use it for the software you would never have written at all.

> don’t use it for software you otherwise would have written by hand; use it for the software you would never have written at all

Very well put. Maybe a will try out vibe coding some time after all.

Even better use it to prototype, to play, to fling spaghetti at the wall. If something works but the AI code sucks, rewrite the thing that works by hand.

This could massively accelerate experimentation.

Currently, my team and I use v0, (and try Lovable, or Bolt) as tools for fast prototyping. Mostly, Product Owners and Architects create functional prototypes to support Epics. We use these prototypes to communicate with stakeholders, suggest solutions, and verify requirements. We discard the code from these tools and sometimes only take screenshots.

This is a sane approach. I'll try to propose this to the team to see if this sticks, hehe.

disclaimer: building a competitor (https://getmocha.com)

Lovable and bolt took a massive shortcut: they outsourced the backend to a third party (supabase).

This makes their ceiling to build "useful" software incredibly low.

The right approach takes a lot more time: pick an opinionated framework (think ror) and build up a full stack app builder from the ground up.

Took us months and months of work to get it working, but now people _can_ build "useful" software (thats our bar)

Is this similar to the "vibe" code tool sold to Wix?

yes same category

Im always hunting for someone whos solved "sandboxing" because setting it up myself is so damn painful.

Anyone ever find a good product in this space?

Beam seems close, but not quite

what is missing for you?

Blaxel & E2B use microVMs which is usually the standard for this kind of worloads. E2B feels more ephemeral while Blaxel feels more stateful, depends on what you're looking for. Daytona uses containers, less secure than VMs.

I heard Vercel & Cloudflare launched a sandboxes offering too. Haven't tried it yet but i'm naturally wary of the marketing fluff around their annoucements

i see they mostly offer api to run the sandbox on their infra...is there a way to host the sandboxes self hosted?(how much memory/compute needed?)

A list of sandboxing techniques and products: https://github.com/restyler/awesome-sandbox

Isn't the whole point of Bolt/stackblitz that you can run node js clientside via wasm, so it's more lightweight?

Did they migrate away to a more server heavy model?

"We’ll be using FastMCP, a lightweight framework for building model-control-plane servers"

Article written by AI (and not reviewed by humans) that doesn't know MCP is model context protocol?

Or author being intentional for some weird reason?

Looks like AI slop

We initially wrote this for a less technical audience (where we spelled out MCP), then edited it to post here - it's not AI, it's just bad editing from my part. Fixed now.

I'm confused by your explanation. You originally spelled out MCP and then edited it. Did you originally have it as model context protocol and then edited it to model control plane? Or did you originally have it spelled out as model control plane and missed it in editing?

The Model-Context-Protocol/Mode Control Plane mix up seems to come up a lot in AI slop articles. I assume its because most AI models’ training cutoff was before Model context protocol became a big thing.

You can see it here too https://www.unleash.so/post/model-control-plane-mcp-for-ai-a...

And soon, articles like that one will be ingested into next generation of models, and they would become a bit more nonsensical...

AI models are becoming better and better though. Data quality is a known issue and this won’t stop scaling up

Looks like an ad... BTW there are more sandboxes code- here is OSS one: Daytona https://github.com/daytonaio/daytona

The only Beam-specific part are the sandboxes, but those can easily be swapped out for the vendor of your choice. The architecture we described isn't exclusive to our product.

Beam is fully OSS BTW: https://github.com/beam-cloud/beta9

Fighting what you perceive to be an ad... with another ad?

Reply on news.ycombinator.com