Bloom: Deploys You Can Watch Grow

Inspiration

Tools like Lovable, Bolt, Cursor and v0 let almost anyone build an app. The trouble starts when it's time to put that app online. Suddenly you're looking at build logs, failed health checks and environment variables, and a line like Error: DATABASE_URL is not set with a stack trace under it tells a first-time builder nothing. A lot of good projects stall right there and never leave the laptop.

Deployxa already deploys apps made with these tools. We wanted to design the deploy experience around it for someone who has never deployed anything: calm, easy to read, and always clear about what to do next.

What it does

In Bloom, each project is a plant, and a deploy grows it through four stages. At Seed, Bloom copies your code. At Sprout, it builds it. At Bud, it checks that the app starts and answers. At Bloom, the app is live with a secure web address.

Your garden shows all your apps at once. A flower is live, a drooping plant needs one thing from you, and a seed isn't online yet. Open a project and you get a four-step stepper and an activity feed written in plain English. The raw technical log is still there, one click away, for anyone who wants it.

When a deploy fails, the plant droops and Bloom tells you what went wrong. In the demo, the app needs a database it doesn't have. A guided fix adds one, the deploy runs again, and the plant grows back. Your live version stays untouched the whole time.

Every live version is kept on a version vine, so you can rewind a bad update in one click.

The landing page tells the same story. The plant grows as the page loads, a pinned scroll section walks through the four stages, and a slider lets you drag between a raw build log and Bloom's explanation of the same error.

Deploys are simulated in the browser with mock data, so you can try the whole flow, failure and recovery included, without breaking anything. Bloom itself runs on Deployxa.

How we built it

We started with the design. The direction was organic and biophilic, and the plant metaphor came first: Seed, Sprout, Bud and Bloom map one-to-one onto clone, build, health check and live. We held ourselves to a few rules. The raw log is never the default view, there's no complex onboarding, and every screen suggests something to do.

We called the palette "greenhouse mist": spruce ink on a pale green mist, leaf green for live, pollen amber for in progress, berry red for needs attention, and pink for the flower. Headings and project names are set in Lora, the interface in Nunito Sans, and JetBrains Mono only appears inside the technical details.

The frontend is React and Vite, with Motion handling the animation. That covers the spring physics and the shared-element transition where a plant in the garden morphs into the big plant on the project page. It also drives the scroll-linked effects, a bee cursor that pollinates plants, and a sky that shifts from dawn to night with fireflies as you scroll.

To fake the deploys, each project runs a scripted sequence of events. Every event carries a plain-English line and the matching raw log lines, so the friendly feed and the technical log always describe the same thing.

The site is built as static files and deployed on Deployxa.

Accessibility

Text contrast meets WCAG AA or better, and focus rings are always visible. Every state has a text label and an icon as well as a colour. Touch targets are at least 44px. The comparison slider and the version picker both work with the keyboard. Deploy progress and form errors are announced to screen readers. With prefers-reduced-motion on, every animation jumps straight to its end state, and the custom cursor only appears on devices with a fine pointer.

Challenges we ran into

Our first palette was cream, serif and terracotta, and it looked like a lot of AI-generated sites. We threw it out and built the greenhouse palette instead.

The growing plant is the heart of the product, but it couldn't be the only way to follow progress. So every animated state also has text, an icon and a screen-reader announcement, and everything still works with motion turned off.

Failure was the hardest part to get right. A drooping plant had to say "this needs you" without feeling like a telling-off, and it still had to be exact about what broke. What worked was a plain-English explanation with a single fix next to it, and the real log one click away.

Accomplishments that we're proud of

We're proudest of the full failure-to-recovery flow: you see the problem, understand it, fix it, and watch the plant grow back. The before/after slider is a close second, because one drag shows why plain-English errors matter. We also like that the interface manages to be playful and accessible at the same time, and that we shipped it on the sponsor's own platform.

What we learned

A strong metaphor does a lot of the information architecture for you. Once "project = plant" was settled, most of the states, colours and copy followed from it.

Writing error messages turned out to be design work. The wording of one sentence decides whether a beginner gives up or clicks "Fix it".

And it's far easier to plan for reduced motion from the start than to bolt it on at the end.

What's next for Bloom

The first step is connecting Bloom to Deployxa's real deploy events instead of the simulation. After that we want more guided fixes, for missing environment variables, wrong start commands, port mismatches and build-time errors. We'd also like preview deploys to show up as buds on a branch, and a guided custom-domain setup. Then we want to put it in front of first-time builders and watch where they get stuck.