An AI image wrapper looks deceptively simple at first glance: upload an image, pass an instruction to a model API, and render the output. That works fine for a weekend prototype, but it falls apart quickly when building an actual product.
While developing ImagineMyHouse, I gradually added more specialized tools: room redesign, virtual staging, object removal, relighting, floor-plan visualization, and panorama generation.
From a high level, every tool shared the exact same loop:
Image in → Pipeline processing → Image out
By the time the project grew to 16 workflows, I ran into an architectural fork:
- Build 16 separate mini-apps and maintain endless duplicate code.
- Force 16 completely different user intents into a single, vague "AI image generator" prompt box.
The workable middle ground was clear: share the workspace infrastructure, but model each user intent as a distinct workflow configuration.
Users Don't Think in "Image Generation"
Developers usually describe these products by their technical mechanism: "The user uploads a picture and the model transforms it."
Users describe the job with specific constraints and expectations:
- "Redesign this living room, but don't move the windows or walls."
- "Clean up the clutter on the floor, keep everything else."
- "Furnish this empty listing photo for a staging preview."
- "Change the lighting from noon to dusk without altering materials."
The underlying pipeline might share components, but the user contract is fundamentally different for each task.
| Workflow | What May Change | What Must Remain Stable |
|---|---|---|
| Room Redesign | Furniture, materials, colors, lighting | Camera perspective and room geometry |
| Room Cleanup | Movable objects and clutter | Flooring, walls, door frames, windows |
| Virtual Staging | Added furniture and decor | Empty-room boundary and lighting angle |
| Relighting | Light source, direction, atmosphere | Objects, textures, room composition |
| Floor-Plan Render | Visual style and rendering textures | Room boundaries and plan dimensions |
| Panorama | Field of view and projection | Scene identity and visual continuity |
A workflow isn't just a prompt template with a label. It defines what the user expects the system to preserve versus what they want transformed.
Defining Workflows Through Explicit Constraints
When building the first few tools, creating dedicated pages and forms felt fast. But as the number of features scaled, fixing layout bugs or updating API wrappers across a dozen slightly different components quickly became unsustainable.
To fix this, I abstracted the workspace into two distinct layers:
1. Shared Workspace Infrastructure (Reusable)
- Asset upload validation and image compression
- Authentication and rate limits
- Asynchronous task polling and job status recovery
- History persistence, exports, and common error boundaries
2. Workflow Definition Layer (Specific)
- Targeted input constraints and guidance copy
- Active UI controls (e.g., style selector vs. lighting slider)
- Intent-specific preservation parameters and negative constraints
- Tailored example galleries and contextual failure messages
This separation keeps the codebase maintainable while ensuring each tool remains focused on a single job.
Normalizing Intent Before Provider APIs
Another helpful boundary was decoupling the workflow intent from third-party AI APIs.
The frontend communicates with an internal domain model:
type WorkflowRequest = {
workflowId: 'room-redesign' | 'virtual-staging' | 'cleanup' | 'relighting';
sourceImage: string;
preservationLevel: 'strict' | 'moderate' | 'loose';
params?: Record<string, string | number>;
};
The backend maps this normalized payload into provider-specific parameters (masks, control conditioning weights, or prompt templates).
If a model provider changes or a better fine-tune is deployed, the frontend workflow contract remains untouched.
Preservation Is a Product Requirement, Not a Prompt Suffix
Tacking "preserve original room layout" to the end of a prompt rarely solves structural drift.
Different workflows live along a preservation spectrum:
Relighting → Cleanup → Staging → Redesign → Plan-to-Render
(Strict structural lock → High creative latitude)
For every tool, you have to decide:
- Which anchor points define the image's identity?
- Where is drift acceptable, and where does it break user trust?
- What conditioning signals (edge maps, depth, segmentation) are required?
In interior redesign, moving a structural pillar or shifting a door frame is an immediate failure, regardless of how good the aesthetic looks.
Reliable Job States Build User Trust
AI generation takes anywhere from 5 to 15 seconds. Users refresh tabs, hit network drops, or trigger concurrent jobs.
A resilient UX treats generation as an asynchronous background job rather than a transient React state:
- Acknowledge request receipt immediately with a unique job ID.
- Maintain job state in the database so progress survives tab reloads.
- Ensure billing and credit deduction are idempotent to prevent double-charging on network retries.
- Provide clear error reasons rather than generic infinite spinners.
When Does a Workflow Deserve a Dedicated Route?
With a unified workspace engine, spinning up new routes is cheap. But creating pages for minor keyword tweaks creates shallow experiences that confuse users and dilute SEO.
A separate route makes sense only when at least two of these factors change:
- Input Type: A 2D blueprint requires different validation and guidance than a wide-angle bedroom photo.
- Control Requirements: Staging requires empty room presets; cleanup needs brush/mask tools rather than style cards.
- Definition of Success: The criteria for evaluating a clean floor differ entirely from a multi-style re-render.
If the input, controls, and output expectations are identical, it belongs as a preset inside an existing workflow—not a separate URL.
Evaluating Workflows by User Action, Not Just HTTP 200
An API returning a 200 OK doesn't mean the user got what they wanted.
Rather than looking solely at API completion rates, evaluate tools against post-generation behavior:
- Keep / Download Rate: Did the output match the user's intent closely enough to save?
- Immediate Re-roll Rate: Are users constantly re-generating due to bad default weights?
- Workflow Abandonment: Are users dropping off at the configuration stage because of irrelevant settings?
Tracking quality at the workflow level reveals which specific transformation promises need tighter tuning.
Summary
Scaling from a prototype to a multi-tool product isn't about stringing together more API endpoints. It comes down to decoupling generic infrastructure from domain-specific workflows and treating preservation rules as core application logic.
For developers building multi-tool AI apps: what is your threshold for keeping features in a unified workspace versus splitting them into separate bounded micro-apps?
Top comments (0)