Projects

Build story / 01 · Demo project

Tanaw AI.
A new perspective
on familiar places.

A conversational workspace for exploring how a street or public space could change—with a plan you can question, a concept you can compare, and limitations you can see.

My role
Product design & full-stack development
Built with
Next.js · TypeScript · OpenRouter · Supabase
Status
Working local MVP · Not publicly deployed
Focus
Multimodal AI · Human approval · Visual interaction
The Tanaw AI starting workspace: pinned notes on the left, photo upload in the center, and the design conversation on the right
01 / The workspace A photograph starts the conversation. Click any screenshot to inspect it at full size.

A familiar place, a different possibility.

A street photograph can make a planning conversation more concrete. Where could a pedestrian path connect? What should stay? Which part of the scene needs attention? I built Tanaw AI to let someone explore those questions without having to write a complete design brief first.

The name comes from the Filipino word tanaw, meaning a view or outlook. Its tagline, “Bagong tanaw. Bagong posibilidad.”, reflects the idea behind the app: looking again at a place you already know.

The MVP accepts an uploaded or pasted photo. From there, a design partner helps shape a proposal, generates an edited concept after approval, and presents the original and result in a comparison canvas. The output is a visual study, not a site survey or construction plan.

Plan before generating.

The first version went directly from a written brief to an image. It produced a result, but there was little opportunity to discuss what the model intended to change. I moved planning into a conversation so the user could refine the proposal before spending an image-generation call.

The planner can suggest relevant improvements beyond the initial request, while keeping stated preservation constraints. Each reply includes a folded plan with proposed interventions, reasons, tradeoffs, preserved features, and conditions that need verification.

Some feedback is easier to point at than describe. Numbered pins connect notes to locations on the original image. Those coordinates and notes become part of the planning context, allowing requests such as “add a pedestrian lane here” to carry a spatial reference.

Two pinned notes identify a lamp post and a proposed pedestrian lane, alongside an AI reply and a folded four-change plan
02 / Shape the plan Spatial notes and conversation feed the same proposal. Image generation remains a separate action.

Inside the AI workflow.

I separated planning, rendering, and visual review into distinct model calls. Next.js handles the interface and server routes; OpenRouter connects the models; private Supabase Storage holds the original and generated images, accessed through expiring signed URLs.

  1. Read the place.The planner receives the photo, conversation, previous proposal, and pinned notes. It returns a conversational reply and a structured design plan.
  2. Approve the proposal.The server signs a proposal receipt tied to the image and plan. Rendering verifies that receipt, keeping the approved proposal connected to the image-generation request.
  3. Generate the concept.The image model receives the original photo and approved plan, with instructions to preserve recognizable geometry and respect access constraints.
  4. Review and compare.A vision model compares the original and generated images. The app displays the result and posts any review notes in chat.

Long model calls also need an understandable interface. The canvas shows an animated drawing state, while the conversation panel explains that generation and checking are in progress. These are activity indicators, not invented percentages.

A Drawing the possibilities overlay on the canvas with a matching generation status in the conversation panel
03 / Make waiting understandable The canvas and chat both acknowledge the work in progress.

Make the limitations visible.

During iteration, one generated concept altered a bridge in a way that broke its structural continuity. That failure shaped both the prompts and the review step: preserved structures and usable access needed explicit attention.

The reviewer also proved capable of being too strict, treating conceptual changes as if they needed construction authorization. I revised that distinction and made review advisory. A flagged concept is still shown, with the concerns attached to the conversation so the user can inspect, revise, or deliberately generate another version.

Before-and-after slider showing the generated street concept while chat notes flag a missing requested pedestrian lane and remaining overhead wires
04 / A result with context This example shows both the generated concept and review notes about requests the image did not fully follow.

The comparison slider helps a person inspect changes directly. The AI review is an additional signal, not proof that a design is safe, feasible, or complete. If the review cannot finish, the app says so and still presents the generated image.

What I learned.

The most useful changes were about giving the user control: separating conversation from rendering, keeping plans beside their replies, showing sent messages immediately, and making the generation state visible in both panels.

This project demonstrates a complete local loop from photo input to a reviewed visual concept. It also makes the remaining limits clear: image edits can miss instructions or distort geometry, the reviewer can make mistakes, and a photograph cannot establish engineering feasibility.

Street imagery visible in the supplied demo screenshots includes Google Maps attribution. This project does not integrate Street View or provide a Street View capture feature.

Back to projects