Turning a room photo, a description, and three measurements into a design plan someone can actually act on.
Interior design tools are built for people who already have the vocabulary. They ask for a floor plan, a budget, and a style you can name. First-time homeowners and students renting a room in Malaysia have none of those. They have a phone, a room they're not happy with, and no idea what to search for.
The gap isn't inspiration; Pinterest solves that. The gap is the step after inspiration: what actually goes in this room, at these dimensions, in this style, that I can buy here.
Take the inputs a person genuinely has: a photo, a sentence, three measurements, and a style they can point at. Then return a specific, buyable plan.
Three tiers and two model calls. The Flutter client owns the flow and the state; the Express API owns identity and persistence; each AI service is individually replaceable, because every one of them has a mock implementation behind the same interface.
Flutter client
Express API
Data & AI
The same request end to end. The dashed path is what happens when a dependency fails.
Scoped in Chapter 1 of the report, then built in order. Each one had to work on its own before the next began.
01
Register, log in, stay logged in, recover a lost password.
Email and password registration against the Express API, with JWTs issued on login and sent as bearer tokens on every subsequent request. A one-time-code flow over email handles password resets, so a forgotten password doesn't mean a lost design history.
02
A photo, a description, dimensions, and a style, all in one pass.
Four input types in a single flow: an image from the camera or gallery, free text, three numeric dimensions, and a categorical style choice from six presets: Minimalist, Scandinavian, Industrial, Tropical, Modern, and Japandi. Dimensions are normalised to metres on the way in, so the rest of the system only ever deals with one unit.
03
Vision model reads the room; language model writes the plan.
GPT-4o analyses the photo and describes what is actually in the room, including the lighting, existing furniture and constraints. That analysis, plus the user's text, dimensions, and style, is composed into a single prompt for Claude, which returns the plan as structured data rather than prose: layout recommendations, a named colour palette with hex values, and decoration ideas.
04
Real products, not generic advice.
The plan is matched against live IKEA product data through the Zyla API Hub, so a recommendation comes with a product, a price, and a link, which is the difference between 'add warm lighting' and something you can put in a basket.
05
Save it, revisit it, share it.
Completed reports are saved per user in MongoDB Atlas and listed in a history screen. Any report can be shared through the device's native share sheet, which is how alpha testers actually passed designs to the people they live with.
The choices I would be asked about in an interview, and the reasoning behind each one.
GPT-4o only looks at the photo. Claude only writes the plan. Neither does both.
Why: Extraction and generation fail differently. Keeping them separate means a bad room reading is visible in the analysis before it contaminates the plan, and either model can be swapped without touching the other.
The language model returns typed fields, parsed into a DesignReport model. They cover layout recommendations, a colour palette of name and hex pairs, and decoration ideas.
Why: Prose can't be rendered as swatches, saved to a history list, or matched against a product catalogue. Fixing the shape at the model boundary is what makes the rest of the app possible.
With no API keys present, the vision model, the language model, and the furniture API all fall back to mock responses, and the full flow still runs.
Why: An alpha test or a supervisor demo shouldn't depend on a key being live and in quota. The failure I was most likely to hit was the one I designed for first.
The API base URL resolves in a fixed order: a compile-time --dart-define, then .env, then a platform default, which is 10.0.2.2 on the Android emulator and localhost everywhere else.
Why: I was switching between Chrome and an emulator constantly. Editing a config file every time was a step I would eventually forget, so I removed the step instead of trying to remember it.
Provider, with a notifier per concern.
Why: One developer, a linear flow, and no code generation step. State management was never the bottleneck in this project, and something bigger would have added a build step it didn't need.
Partway through, I deleted the codebase and rebuilt it leaner.
Why: The first version had grown organically until I couldn't hold it in my head or explain it in a supervisor meeting. Starting again with what I'd learned cost less than continuing to work inside something I no longer understood.
Early responses were well written and useless. The app needed fields and got paragraphs. The fix was a prompt builder that states the exact schema, and parsing that treats every field as potentially absent, defaulting rather than throwing when the model improvises.
Two model calls plus a product lookup takes real time, and a spinner over a frozen screen makes that feel broken. The wait became its own screen that reports which stage is running.
Furniture data comes from a third-party API with its own rate limits and outages. Product lookup is isolated behind one service with a mock fallback, so a catalogue failure costs the product links, not the design plan.
Testers entered dimensions in whatever unit they think in. Values are converted at the boundary and stored in metres, and the report renders a single canonical label, so no downstream code ever has to ask what unit it is holding.
The code is public, and I'm happy to talk through any part of it, including the parts I'd build differently now.