My Pod Planner
A light-zone-aware planning tool for owners of Gardyn indoor hydroponic gardens, designed and shipped with AI as the implementation partner. Live at mypodplanner.com.
A solo indie product I designed and shipped in two weeks, with AI as the implementation partner. Launched April 2026; the 4–6 week return cadence I built the case study around validated within three weeks. A week‑one deployment incident exposed where AI‑assisted work needs hard production guardrails, which now drive my working pattern.
- Role
- Solo Product Designer & Builder
- Scope
- Product strategy, UX, interaction design, AI‑assisted implementation
- Stack
- Claude (AI implementation partner), Supabase, Vercel, PostHog
- Timeline
- Two weeks to initial launch
- Status
- Live beta product
Gardyn owners had been manually planning pod layouts in charts and spreadsheets since the product's inception. The issue wasn’t missing information. It was missing spatial intelligence.
I designed and shipped My Pod Planner, a light‑zone‑aware planning tool that helps Gardyn owners decide what to plant, where to place it, and what to replant next.
The product launched publicly in April 2026 and quickly developed a highly engaged early user base, with users returning for long planning sessions and contributing feature ideas within days of launch.
The product remains in active beta while I explore premium planning and custom‑plant functionality.
For four years, Gardyn owners had been planning pod layouts in a community‑maintained spreadsheet. Every 4–6 weeks, when their pods exhausted, they returned to it. Users kept asking the subreddit for a proper app, but the real issue wasn’t access to information.
It was interaction design.
Gardyn’s ecosystem provided:
- a catalog of plants
- a generic light map
- and scattered documentation
Users still had to mentally translate that information into a physical layout. The spreadsheet they’d been using for four years couldn’t model:
- spatial relationships
- light‑zone behavior
- stagger timing
- or real planning workflows
The problem was fundamentally visual.
I treated the existing Gardyn community on Reddit and Facebook as a large‑scale behavioral research archive.
Instead of formal interviews, I analyzed years of:
- Reddit discussions
- Facebook conversations
- workaround spreadsheets
- planting frustrations
- and recurring failure points
I focused on:
- where users abandoned planning
- how they described the frustration
- and what behaviors repeated across experience levels
After launch, feedback from the Reddit community and session recordings became the primary research tool.
Within 48 hours, I had enough real usage behavior and feature requests to begin iterating meaningfully.
Several patterns emerged quickly:
- One user spent more than 90 minutes planning across two sessions
- Another generated 673 clicks and 192 keystrokes in a single hour
- Multiple users named their maps, which emerged as a strong ownership signal
Three features shipped within hours of discovery, in response to observed behavior:
- Made the tags beneath the map clickable after noticing users click them and get nothing.
- Removed the email confirmation step after noticing a user abandon the site at that wall.
- Replaced the wizard’s empty map with a searchable plant list after noticing even the most dedicated users took more than an hour to fill it in, clicking into each field to search for one plant at a time.
I designed and shipped five primary workflows:
A structured onboarding flow that helps users configure their Gardyn unit without requiring horticulture expertise.
One 3x10 and another 2x15 light‑zone‑aware layout with drag‑to‑swap, search‑to‑place, visual light intensity mapping, and persistent state.
A persistent inventory system for pods users already owned.
A lightweight no‑signup planning flow designed to reduce commitment friction.
Instead of a single “remove plant” action, the system introduced two distinct outcomes: Pick a few leaves or Harvest the whole plant. If it’s not ready, users can choose to snooze it 3 days, 1 week, or 2 weeks.
Warn, don’t block.
My first instinct was to block “bad” placements outright. The system would refuse to let a high‑light plant go in a low‑light slot. Reading the Reddit threads is what changed my mind: Gardyn owners often end up with more plants of one light level than they have slots for that level. Blocking them in that case forces a user to either put a plant somewhere they don’t want it or, more likely, close the tab and not come back. I redesigned the flow to flag the consequence inline (e.g. Sweet Thai Basil in a low‑light slot, prefers mid) and let the user decide.
Once “warn, don’t block” landed in the placement flow, the same stance carried into three other parts of the product:
- Auto‑place recommendations. The system suggests a layout but doesn’t enforce it. Users drag plants between zones to compare, which is what they were doing anyway.
- Tip persistence. Layout banners stay until the user dismisses them, instead of disappearing on the next unrelated edit and leaving the original issue unresolved.
- Mid‑light bolting validation. Plants that bolt under high‑intensity LEDs (basil, cilantro) are flagged inline with a tap‑to‑detail explanation, not blocked. The same callout pattern as the placement warning.
Three separate decisions, one underlying stance: trust the user with information, give them control, and don’t second‑guess explicit choices.
AI pod identification.
An early idea of mine: a flow where users could photograph their existing pods and have AI add them to the Pod Shed automatically. As I scoped it with Claude, two concerns came up. The only secure implementation pattern would have required each user to provide their own image‑recognition API key, which pushed the planner toward a more technical audience than it was meant to serve. The recurring per‑user inference cost would also have made the free tier hard to keep free. I decided not to ship it.
Shortly after launch, a deployment accidentally broke both PostHog analytics and Supabase persistence.
The issue wiped several early users’ saved layouts and cost the first two days of launch analytics.
I identified affected users manually and communicated with them directly.
The experience fundamentally changed how I approach AI‑assisted implementation and production safeguards.
Going forward, I would introduce a mandatory pre‑deploy review layer where Claude reviews:
- migration safety
- persistence‑sensitive flows
- analytics integrity
- and production‑risk edge cases separately from happy‑path behavior
AI accelerated implementation dramatically.
But production accountability still belonged to me.
My working pattern after the incident: AI handles implementation, routine refactors, and feature‑pace work. I treat anything that touches user data, migrations, or analytics as a manual review boundary. Before a change to those areas ships, I walk migration safety, persistence flows, and analytics integrity as separate review passes rather than bundling them with feature work. The separation keeps velocity high on the parts where AI is reliable, and slows me down on the parts where I need to be the one accountable.
Three open questions going into launch: was the 4–6 week planting trigger I built the case study around real, would the community adopt an indie tool, and could AI‑assisted implementation hold quality at launch velocity. Here’s what landed.
The 4 to 6 week planting trigger that opens the case study was a pre‑launch hypothesis. Three weeks after launch, two users from the first‑week signup cohort came back inside that window, independent of each other and without reactivation outreach. Both had been silent since their first session. A third user has since logged two return visits seven and ten days apart, suggesting the trigger moment isn’t only monthly: some users return on a weekly rhythm as well.
A weekend in week 4‑5 stacked further evidence. The site crossed 50 users on Friday. Over the next two days I logged two deep‑engagement sessions from visitors who didn’t sign up, at 11 and 40 minutes respectively, both well above the typical web session. Both confirmed the freemium logic: transient use stays free, only saved state asks for a signup, and the users who do convert are self‑selecting as the segment that wants persistence. A first confirmed non‑signup return visit landed shortly after.
The build itself moved unevenly. Implementation accelerated with AI faster than I’d expected, but prioritization, systems thinking, and production safeguards didn’t. The post‑launch outage made that gap visible.
Open to senior product roles, especially ones where shipping fast and owning the production layer matter together. hello@saribrooke.com.