MicroYards — AI garden design and live price engine

What problem was this solving?

Design inspiration and shopping are normally two disconnected experiences. A generated image is worthless to a consumer if the products in it cannot be bought at a price they can afford.

What did we build?

Generative redesign from a single photo, paired with a live multi-retailer price engine that keeps the result inside the user's budget.

• Photo-to-design generative pipeline producing a plausible redesign of the user's own space.
• Object extraction mapping generated elements to purchasable product categories.
• Live price comparison across Amazon and partner stores.
• Budget constraint solving so the returned basket fits the user's stated spend.

What does it integrate with?

The integration surface technical buyers ask about.

• Generative image provider invoked server-side.
• Retailer product feeds and affiliate endpoints.
• Budget solver sitting between the design output and the basket.

How does the system actually work?

The decision path in order. Client-confidential detail is deliberately excluded.

• 1. Upload — User submits one photograph of their existing space.
• 2. Generate — Server-side generative pipeline produces the redesign.
• 3. Extract — Design elements mapped to purchasable product categories.
• 4. Price — Live lookup across Amazon and partner retailers at request time.
• 5. Fit budget — Basket solved against the user's stated spend and returned.

What made it hard?

The real engineering constraints on this build.

• Generated designs must stay achievable — an image full of products nobody sells is a bad product, not a creative one.
• Retail prices move, so the basket is priced at request time rather than cached indefinitely.
• Image generation cost per user has to stay below the value of the resulting basket.

What was the outcome?

MicroYards ships a consumer product where the AI output is directly actionable rather than decorative. No third-party traffic or revenue figures are published here. No measured performance figures are published for this engagement because the client has not authorised their release.

What capability does this demonstrate?

Engagement band: Applied AI engineering band.

• Consumer-grade generative image pipeline
• Generated-object to real-product mapping
• Multi-retailer live pricing
• Budget-constrained recommendation

How do you stop the AI generating things that cannot be bought?

The design step and the commerce step are separated. Generated elements are mapped to real product categories, and anything that cannot be matched to a purchasable product is dropped from the basket rather than shown as if it were buyable.

Does the price update in real time?

Prices are looked up at request time across the connected retailers rather than served from a stale cache, because a wrong price is worse than a slow one.

Is this the same engine you would build for our business?

The pattern transfers — generate, map to a real catalogue, constrain by budget. The catalogue and constraints would be yours.

A note on what is published here

Case studies on this page describe work Digital Bridge delivered. Client-confidential detail, credentials and internal data structures are deliberately excluded. Where a client has not authorised publication of measured figures, outcomes are described qualitatively rather than quantified — we do not publish numbers we cannot evidence. Last reviewed 2026-08-18.

Related reading

• AI integration services
• AI engagement bands and pricing
• How we de-risk a build

Other builds in the estate

Continuous AI incident triage across four Irish depots: natural-language and image severity classification, Eircode geolocation, dispatch routing and duty-principal escalation. Fifty-plus shipped tools on one platform, including two proprietary scoring algorithms and production generative AI running server-side. A full web-to-print platform with a live design configurator, print-file automation and twenty-nine-plus structured product pages. Jo McAteer, Forever Home Sanctuary, Riversdale House, AI Triangulate, Equi Consignment, RCP Psychotherapy and Time To Change — grouped by what the engineering actually required.

Could this pattern work in your operation?

Every production build starts with a seven-day shadow-mode pilot, so you see the system's decisions against your own data before it touches anything live.

The estimating problem this addresses

Producing a design and a price for outdoor and yard work traditionally means a site visit, measurements and an evening spent on a spreadsheet, which limits how many enquiries a small operator can answer properly. A configuration and pricing engine moves the routine part of that into software so the human time goes into the jobs that actually need judgement.

Where automation stops

Automated pricing is only safe within defined bounds. Awkward access, unusual ground conditions and unclear scope all need a person to look. The engine is built to recognise the cases it should not price and hand them over rather than produce a confident number nobody can honour — which is the failure mode that makes these systems expensive rather than useful.

What does the Microyards design and price engine actually do?

This system takes a customer's layout inputs and turns them into a structured design output with an accompanying price, replacing a process that previously required a staff member to manually configure options and calculate a quote for each enquiry. It works from a defined set of product rules and pricing logic supplied by the business, not from an open-ended model guessing at configurations, which is what makes the output reliable enough to quote from directly. The engineering work was mostly in encoding the real constraints — what combinations are physically possible, what pushes a job into a higher pricing tier — accurately enough that the automated quote matches what a person would have worked out by hand.

Where are the human checks and the honest limits of this build?

Quotes above a set value, or configurations the rules do not clearly cover, are flagged for manual review rather than issued automatically, because an automated price is only trustworthy within the range the rules were built to handle. No customer data is used to train any external model; the pricing logic and customer inputs stay within the business's own system, consistent with GDPR. The limit is a real one worth stating plainly: the engine is exactly as accurate as the pricing rules it was given, so any change to the underlying product range requires the rules to be updated, and that maintenance step is part of keeping the tool trustworthy rather than a one-off build that runs forever unattended.

What made pricing and design the two hardest parts to automate together in this build?

Pricing and design decisions are usually handled separately in most systems, but they’re deeply connected in practice — a design change almost always has a cost implication, and treating them as two disconnected steps is where a lot of automated quoting tools fall short. The harder engineering problem wasn’t generating a design option or calculating a price in isolation; it was making sure that every design variation automatically and correctly recalculated cost in real time, without a human needing to manually check the numbers afterwards. That required the underlying logic to genuinely understand the relationship between design choices and cost drivers, rather than applying a flat markup or a rough estimate that would need correcting later. Getting this reliable enough to trust without manual review took considerably more scoping and testing than either the design or pricing component would have needed on its own. It’s a useful illustration of why we treat AI systems like this as genuinely custom engineering work, quoted individually after a proper discovery assessment, rather than something that fits into a standard package — the complexity lives in the connections between components, not any single piece.

How do you validate that an automated pricing engine like this is actually accurate before launch?

Trust is the whole point of a pricing engine, so validation isn’t an afterthought — it has to happen extensively before anything goes live in front of real customers. Our approach involves running the automated engine against a wide range of known scenarios and manually verified figures, checking that its output matches what a knowledgeable person would calculate by hand across as many edge cases as we can reasonably construct, not just the straightforward middle-of-the-road examples. Edge cases matter more than typical cases here, because a pricing engine that handles ninety percent of scenarios correctly but silently miscalculates the unusual ten percent is arguably more dangerous than no automation at all, since errors can go unnoticed until a customer or the business itself catches a mistake after the fact. We also build in sanity-check logic that flags outputs falling outside expected ranges for manual review rather than letting every result pass through unchecked, which gives a practical safety net without undermining the efficiency gains of automating the process in the first place. This kind of rigorous testing phase is a significant part of why custom pricing engines take real time to build properly.