Sproutly.

Background

Sproutly turns a photo of someone’s outdoor space into a personalised, ecologically grounded planting plan in under five minutes. It exists because people who would rather plant than gravel over their gardens give up at the planning stage — from decision paralysis, not lack of care.

I built it alone: product, design, architecture, and code. It’s live, backed by German government soil and climate data, and it makes a promise reality can check — the plants either survive or they don’t. So this case study is about process, not pixels. Anyone can ship an AI demo. The harder question is what has to be true before you let an AI-assisted system make a claim a user acts on.

The hypothesis

I started with a bet that had nothing to do with gardens:

One person, with AI assisting, can take a real product from idea to production.

Not a prototype. A product with authentication, per-user data isolation, external government data, and consequences when the data is wrong. What follows is the result, including the part that didn’t hold.

The system I built

I didn’t prompt my way through this. I built a workflow and refused to leave it: every feature passed the same five gates, each with its own checklist and its own approval point.

The AI features went through exactly the same gates as the login form.

But the gates aren’t what mattered most. An AI session forgets everything the moment it ends, so I made the project remember instead: a live status index, one specification per feature, and every production lesson written back into the spec that owned it. That came to roughly 5,000 lines of specification against 23,000 lines of code — not documentation written afterwards, but the working memory each session began by reading.

Spec the contract, not the cleverness

“Make the plan curation good” is a wish. It can’t be tested, so it can’t be shipped.

The validation lives in one module used by both the server and the browser, so neither can bypass it. That reduced the model’s job to the two things it’s genuinely good at — composition and explanation — and left everything checkable to code.

The safety net came first

Before any model touched plan generation, the guardrail existed: run the engine across 252 sites — every realistic combination of sunlight, soil, space size, and hardiness zone — and assert that not one recommended plant violates a hard survival rule.

I wrote that test months before AI entered the feature. Curation inherited the net for free, because the AI never got to widen the pool — it only reorders and explains what the rules have already approved.

Adding AI to the most load-bearing feature in the product turned out to be basic. Basic was the goal.

Where the model needed a human

To build the plant catalogue, I had AI infer species traits from open government data, then checked its work against an independent botanical source.

It got “native to Germany” wrong on roughly 40% of a fresh batch of species, always in the same direction. Same rate twice, on two different batches — not a bad prompt I could fix, but a boundary of the approach.

So verification became a pipeline step rather than a hope: AI infers, a human confirms, and anything low-confidence is blocked until someone signs it off. The AI still did work that would have taken weeks by hand.

It just doesn't get the last word on a claim someone might plant their garden on.

What production taught me

“We don’t know” has to be a real value. A partial failure fetching weather data quietly wrote a zero where a measurement should have been. The app read that as a mild winter, and the winter survival check silently began passing everything. Nothing errored. I found it only while building a feature designed to be honest about uncertainty — and the fix was structural: unmeasured values now stay empty, and the status reports itself as partial.

Speed budget beats model prestige. The larger model answered in about 17 seconds against a 15-second timeout, so every plan would have quietly fallen back to the rule engine. A smaller, faster model answered in seconds, with copy just as good.

Both fixes went back into their specs the same day, so no future session can reintroduce them.

Where I chose not to use AI

The app shows a survival confidence band — “worth checking”, with the specific conflict and how to fix it — not “87% survival chance”. The biodiversity indicator makes a concrete claim: supports pollinators and birds, blooms around seven months. Not a score out of 100.

Both would have been trivial to generate and both would have been invented. With no outcome data to calibrate against, a percentage is a confident lie — and trust is the entire product.

Deciding where not to put AI turned out to be the same skill as deciding where to put it.

Results

• Live in production, from first specification to deployed product, built solo
• The core journey — scan, plan, review, shopping list — shipped in seven days
• Three AI integrations live: photo understanding, plan curation, catalogue enrichment
• 553 automated tests, and zero survival-rule violations before or after AI entered the system

Reflection

The bet held, with one correction. The bottleneck was never how fast AI writes code — it was how clearly I could specify what I wanted, and whether the system could check the result without me reading every line. Speed was never the constraint. Verification was.

Three things I’d carry into any team. Clarity beats prompting — a testable contract outperforms a clever instruction. Design the failure path first — if the degraded experience is genuinely fine, the AI path is safe to ship. And process compounds — the first feature through the workflow was slow; by the end the same gates ran like a production line.

Working with AI rewards the discipline good product work always has: knowing precisely what you’re asking for, and being honest about what you can prove.