I wanted a practical answer to one question:
Can I preview a yard makeover from a real photo before spending money?
Generic AI image tools make pretty gardens. They are worse at keeping your actual house, fence, and proportions. So I built LandscapeAI — upload one outdoor photo, pick a style, generate a design concept.
Live app: landscapedesignai.net
This is a short build log: stack, architecture, and the bugs that mattered.
The product
Users upload a front yard, backyard, garden, patio, or balcony photo. They choose a style (modern, cottage, zen, Mediterranean, xeriscape…), add optional goals like privacy or low maintenance, then generate a concept.
New users get a small free starter allowance. Extra runs use credits sold as one-time packs.
Clear boundary helped a lot:
- Good for early visualization and style comparison
- Not construction drawings, permits, or guaranteed plant lists
Narrow scope made the engineering shippable.
Stack
| Layer | Choice |
|---|---|
| App | Next.js 15 |
| Deploy | OpenNext + Cloudflare Workers |
| DB / Storage | D1 + R2 |
| Auth | NextAuth (Google) |
| Payments | Creem |
| Image gen | kie → fal → Replicate |
Cloudflare end-to-end kept infra simple for an early AI SaaS: compute, database, storage, DNS in one place.
Architecture
Everything goes through one gateway:
Upload photo + prompt
→ auth + credit check
→ content moderation (fail closed)
→ provider router (kie / fal / replicate)
→ save result to R2
→ decrease credits
One route for generation means credits, safety, failover, and logging stay in one place. I recommend this for any AI image product.
Three lessons from production
1. Multi-provider fallback is worth it
AI image APIs fail, rate-limit, or run dry. A tiny router saved the product:
- primary: kie
- fallback: fal
- third: Replicate
Users care that Generate works, not which vendor won.
Also: some models reject data URLs for reference images. They want public URLs. I upload the user photo first, then pass the returned URL into generation. If you are doing photo-to-image editing, assume that early.
2. Credits beat “unlimited”
Image generation has real unit cost. LandscapeAI uses starter credits + one-time packs instead of forcing subscriptions first.
Yard redesign is often a short project. People try a few styles, then stop. One-time packs match that better than a monthly plan.
3. AI payments need compliance, not just checkout
For AI image products, payment providers may require:
- visible paid pricing before purchase
- consistent support email
- explicit NSFW prohibition in Terms / AUP
- moderation on every prompt before generation
My rule: no prompt reaches the model without a moderation decision. Block on deny/flag, and fail closed if moderation is down.
The bug that looked like “AI is broken”
One production error was:
Upload failed: 400 Bad Request
Generation had already succeeded. R2 upload failed because production storage config/secrets were wrong. From the user’s view, the whole feature was dead.
For AI apps, success means all three:
- model success
- storage success
- credit ledger success
Log them separately.
What I’d do earlier next time
- Build the generation gateway first (credits + moderation + providers)
- Treat storage secrets as launch-critical, not optional
- Show pricing packs before payments are fully polished
- Log moderation success, not only failures
Try it
👉 Generate an AI landscape design from your yard photo
Sign in, upload one outdoor photo, and use the free starter designs.
If you are building a similar AI SaaS, comment with your stack — happy to compare notes on provider fallback, Cloudflare deploys, or credit packaging.
Top comments (0)