Building FloorMind: AI Floor Plans That Stay Editable — Even Offline

Aug 2026 · 3 min read

floor

I shipped FloorMind — a mobile AI floor plan designer. Prompt for a layout (or start from a template), edit rooms and furniture on a plan canvas, check measurements, export PNG or PDF.

Most “AI design” demos produce an image. Images aren’t plans. You can’t drag a wall on a JPEG.

So the product constraint became:

Can natural language produce a structured, editable floor model — and still work when the cloud isn’t there?

The model is the product

All plan geometry is stored in meters. The editor converts to pixels with a view transform. Imperial units are a formatting concern only — never a second geometry system.

A floor is rooms (x, y, w, h), openings (door/window on a wall side with position t and width), and furniture items (kind, pose, size). That schema is what export, measurements, and AI all share.

One UI entry point, two generators

AiPlanService.instance is the only thing the UI talks to.

  • If AI_API_KEY is provided at build time (--dart-define=…), prompts go to Claude with a system prompt that demands minified JSON only: rooms + openings + furniture, meters, adjacent non-overlapping rooms, furniture kinds from a fixed catalog.
  • If there’s no key, LocalAiPlanService runs — same generatePlan(prompt) contract.

Remote failures fall back to local. Empty plans throw. The editor never depends on a successful network call to remain usable.

That mirrors a theme across my recent apps: SellSnap demos on-device; Songora falls back to a local renderer; FloorMind refuses to make “AI generate” a dead button in review builds.

What “on-device AI” actually means here

The local generator is procedural, not a neural net on the phone. It parses the prompt for signals:

  • bedroom count (2 bedthree bedroom, …)
  • open kitchen / open-plan
  • office / workspace / shop / studio
  • balcony / terrace
  • one vs two baths

Then it builds a house (or applies a shop/office/studio template): living + kitchen/dining column, bedrooms stacked, bathrooms tucked, shared furniture (sofa, counter, dining table). A short delay matches the remote UX so the loading state doesn’t feel like two different products.

Quality differs from Claude on purpose. Offline must still produce an editable plan — not a spinner error.

Suggestions that don’t need a model

suggest(PlanFloor) is synchronous and on-device for both implementations:

  • room with no door
  • missing window (except wet/utility rooms)
  • too-narrow rooms
  • bedroom without a bed, living without sofa, kitchen without counter
  • crowded furniture ratio
  • detached rooms that don’t touch neighbors

Capped at a handful of notes. Instant inside the editor. No tokens, no latency, no hallucination about whether a bathroom needs a window.

Editor and export

Templates (empty, studio, 1–3 bed, office, shop). Furniture library. Room settings. Measurements summary. Undo. Export image (PNG) and PDF with dimension tables — watermark-free on premium.

Localization covers many locales; the plan model stays language-agnostic.

What I’d still harden

Shipping the Anthropic key via dart-define is fine for controlled builds; for store scale, proxy generation on a backend (SellSnap’s privilege boundary) so keys never sit in the binary. Validate/repair remote JSON more aggressively (overlaps, missing doors). And keep marketing honest: local mode is a smart procedural planner, not “the same model offline.”

Bet: AI for floor plans only matters if the output is a document you can still edit.

If you’re generating layout with LLMs: return schema, not screenshots — and always have a local path that speaks the same schema.


  • flutter
  • ai
  • floor-plan
  • offline-first
  • architecture
  • structured-output