Skip to content
All work

AI + Product + Landscape Design

Bloomprint

An AI-assisted landscape planning platform that turns homeowner intent into a structured planting plan a nursery can actually fulfill.

In developmentAIDesignLandscapeSystemsProduct
My role
Founder, product designer, system architect

Tools

  • AI models
  • Design rules engine
  • Verified plant data
  • Live inventory model
Fig. 02 — Planning loopBloomprint
INTENTSITE DATAAI PROPOSALRULES +INVENTORYPLANREJECT / RE-PLAN

The model proposes; deterministic logic and validation decide. Anything that fails a constraint returns upstream to be re-planned instead of reaching the user.

Context

Retail nurseries give away landscape advice constantly. A customer describes their yard at the counter, a staff member suggests some plants, and the customer goes home with a few names written down. Nothing is documented, nothing is priced, nothing is checked against what is actually in stock. The customer googles the plants, buys somewhere else, or does nothing at all.

Meanwhile the nursery is sitting on the two things that would make that advice valuable: deep horticultural knowledge and live inventory.

The problem

Generating plant suggestions is trivial. A language model will produce a plausible list in seconds.

The problem is that a list of plants is not a plan.

A real planting plan has structure — a back layer, a mid layer, a front layer. It has repetition, because three of one grass reads as design and one of each of nine things reads as a collection. It has relationships: what is planted next to what, what blooms when, what holds the bed through winter. It has quantities derived from mature spread and bed dimensions, not guesses. And it has to be buildable from plants the nursery has on the ground, in the quantities it actually has, within a budget the customer named.

Every one of those constraints is easy for a model to violate while producing something that reads beautifully.

Why it mattered

Three parties, all of whom lose when the advice stays verbal.

The homeowner, who wants a yard that looks designed and has no way to judge whether a list of plants will produce one. The nursery, which gives away expertise and captures none of it. The staff member, whose knowledge is real and is currently spent one conversation at a time.

Approach

I stopped treating this as a generation problem and started treating it as a constraint-satisfaction problem with a generation step inside it. That reframing drove every significant decision.

Separate the two kinds of plant data. Horticultural facts — mature height and spread, hardiness zone, water needs, bloom period — are stable, expensive to establish, and shared across every nursery. Inventory facts — what is in stock, at what price, in what container size — are volatile and specific to one business. These are different tables with different lifecycles, and conflating them is the root cause of bad plans.

Make verification a gate, not a hope. Unverified horticultural data cannot enter a customer plan. The rule is enforced at query time rather than described in documentation, and any record missing required fields is automatically downgraded out of verified status. A model free to invent a mature spread will produce a plan that physically does not fit the bed.

Encode design rules explicitly. Layering, repetition, and spacing are expressed as rules the plan must satisfy, not as stylistic hints in a prompt.

Keep a human in the loop by design. Every plan is reviewed by a nursery staff member before a customer sees it. That is a deliberate product decision, not a temporary safeguard — it means the nursery stands behind every plan and the customer has a named person to call.

What I built / led

A verified plant knowledge base and a separate live inventory model, with a merge and validation pipeline between them.

A design agent that produces layered, quantified, priced planting plans constrained to real stock.

A customer intake flow covering location, style, bed dimensions, budget, and upkeep tolerance.

A plan result experience with a shoppable plant list, layer badges, layout and installation notes, substitution guidance, and a printable top-down bed diagram with a legend.

A staff review surface, and an architecture designed from the start for white-label deployment, where adding a nursery is a configuration change rather than a rebuild.

A library of realistic intake scenarios used as regression tests, so changes to the design logic are evaluated against known-hard cases rather than vibes.

Result

In development, with a founding nursery partner. The plant library, inventory model, design rules, agent, and result experience are built. Verified plant coverage is the pacing constraint and grows with each verification session.

The verified library is the compounding asset. Each verified plant record is correct for every customer and every nursery, permanently. Plan quality improves as the library grows without any increase in per-customer cost.

What I learned

Generating options is easy. Defining and enforcing what makes a good plan is much harder. That turned out to be the whole project. The model was never the bottleneck.

The corollary surprised me more. The constraints that make the output trustworthy are almost entirely domain knowledge, not machine learning. Knowing that a plan needs repetition to read as designed, that mature spread determines quantity, that a substitution has to hold the same structural role — this is what makes the system work, and it has to come from someone who has done the work.

I also learned to be suspicious of my own demos. A generated plan that looks good on screen and a generated plan a crew can install are not the same artifact, and only one of them is the product.

Looking back

This is the most direct line in my whole career. I spent years producing planting plans by hand at a design firm — layering, spacing, quantities, plant lists, legends. Bloomprint is that same body of knowledge, expressed as a system instead of a drawing.

Screens

More work