Builddrr Changed Gender: Introducing Floras

Introduction

Motivation for Floras came from my earlier experiment of creating a Lovable-like app that I could do Next.js sites with. Since it was early 2025 and the industry was still early I was somewhat limited by technology at that time. Tool calling was something that LLMs didn’t do well, I was rate-limited by Anthropic (thanks a lot) and overall it was a big project and required time.

I wrote about Builddrr originally here in January of 2025 and ever since I’ve had this itch I can’t just scratch. So I decided to give it another try end of this summer and came up with a decent product in one train ride and a busy evening.

I really wanted Floras to have a fresh and somewhat clean look, fix my earlier mistakes on design and architecture decisions, and just keep it all around simple to do what it’s supposed to do.

Build informational websites.

The Stack

Here’s the stack and the deliberate tradeoffs behind it.

Floras is a Next.js app with Convex backend and db, hosted in Netlify, using R2 as object storage and Cloudflare Pages long-term hosting of user sites, and Blaxel for pay-as-you-go microVMs (sandboxes). Autumn Billing for managing payments.

This itself is a very familiar stack for me but a good substitute could have been backend-wise Neon Postgres + Drizzle and Cloudflare Workers or Railway. But I decided to save time and effort by using Convex which I love dearly for its e2e type safety, db schemas being in code as Typescript in the same repo as the application code, good overall DX, and ready-made components for things like R2. Convex also is what’s called a reactive backend so I don’t need to worry about revalidation logic on the app.

Also Convex gives you fewer services to manage and put a credit card into.

I optimized for developer speed, low operational overhead, and free/cheap hosting over maximum flexibility or long-lived sandboxes. This is why I preferred Netlify over Vercel since my Vercel is too full and costs me money already.

The current flow of Floras is simple. You chat with an agent made with AI SDK that has access to design guidelines, read/write files in the sandbox and even start the sandbox. It is a very simple system and needs some work especially site design wise. But it’s good enough now.

User edits sites with that and site previews are done with Blaxel sandboxes that give me very fast boot times and a good SDK to work with.

I skipped Blaxel’s Pro plan, which meant no persistent volumes on the microVMs. Instead I snapshot the workspace to Cloudflare R2 and restore it when the sandbox comes back. Not the cleanest solution, but it lets the work survive longer than the sandbox lifetime. And why I even need storage for sandboxes is that I have limit of how many sandboxes I can have. So I’m essentially freeing unused sandboxes to new users.

I also have retry system for this but if those fail we essentially might lose data. But it requires for our service or R2 being down at upload time and user not informing me/trying upload again later/me not reading errors for 60 days so it’s HIGHLY unlikely but not impossible. I’m taking that tradeoff for now.

Now you might think what the hell? He’s using CF Pages here and not CF Workers. That’s where the tech choice of Astro as client sites comes in.

Astro is pretty cool framework. It’s efficient, light and made for static site deployment. Meaning sites are pre-rendered at build time and deployed as static files. There is some client side JS for forms fetch but thats it. For now.

Astro is easier to run and work with than Next.js. Also static sites remain very fast with zero configurations and deployment to Cloudflare Pages costs literally nothing. This gives me a bit of an edge financially. Of course this limits Astro sites to being fully static but well that’s the case here. Simple static sites for businesses.

One concrete place this philosophy shows up is publishing. Deploying to Cloudflare requires .env variables and we can not put those inside the sandbox where agent has access to. That’s why we stream build output /dist out of the sandbox in Next.js route to /tmp and upload to Cloudflare Pages with Wrangler CLI. Efficient and clean. No need to put environment variables inside sandbox for agent to mess with.

How the agent makes good sites

The agent is intentionally constrained. Here’s how.

A few things that actually keep this from turning into another half-broken agent demo:

Structured planning first. The agent starts with a site planning instead of fragile free-form text that drifts into nonsense after three messages. Then it boots a real project from a template (template repo in Github) and edits files in place inside a named sandbox (floras-{projectId}). Not generating a pile of markdown and praying. Agents write output is typed with Zod so we don’t need to invent custom agent stream parser, like I had on Builddrr. Agent also has design taste skill which allows it to reason a bit about the UI.

Tool activity and summaries stream straight into Convex. The chat and the preview update without any polling glue. Heavy SDKs (AI, Blaxel, billing) stay in the Next.js side so Convex stays light and under the module limits. Which was pretty fascinating that I hit those here. Maybe should dive into that more and share it on Convex discord.

The combination of structured planning + real file editing and reading inside a named sandbox is what keeps the loop from collapsing into the usual agent chaos.

What’s next?

Because this is a pure side project, several things are still missing.

As this is fully side-project strictly worked on when there is nothing else to do it lacks some features. For example we lack testing completely. There is not a single test written. This is due me being the sole developer and the scope is very small. Test suite would be good to have so collaborators output can be verified more easily. But yeah once there is time…

Also observability is completely offloaded to Netlify for strictly error logs. Nothing else so that needs work too.

Also Astro has what’s called Content Collections. This basically means it has built in blog content management system. One good feature would be that agent generates blog and we can in Flora’s app build blog system which would be very useful. But this requires some work and currently don’t have time for it. Feel free to open pr about it :)

Also there is real need for improving agent’s output. This probably requires some skills that agent can use and maybe a retrieval system of examples if skills are not enough. Should balance the effort and output here but we’ll see in the future if there is time to do this.

Highest leverage missing pieces right now are better agent output quality and a proper test suite. Content Collections / blog support would be nice but is lower priority.

Closing Words

Back to the loop: one sentence → live site → ship.

Try Floras. Star the repo. Follow the build.

Repository: https://github.com/valtterisa/floras

The app: https://floras.app