The first version of an AI creation product is easy to imagine.
Add a prompt box, connect a model API, wait for a result, and put a download button underneath it.
That is enough for a demo. It is not enough for a product.
While building SceneFlare, an AI image and video creation platform, I kept running into the same gap. Users do not arrive with provider-shaped questions. They do not want to decide which API payload should contain a source image, how a callback should be retried, or why one model calls a setting quality while another calls it resolution.
They arrive with a creative goal:
The product has to translate that intent into a reliable generation workflow. The model call is only one step inside it.
Model names matter to developers because they describe capabilities, cost, and provider behavior. They matter less to a user who needs a vertical product video before the end of the day.
This changes how I think about navigation.
A model-only directory asks the user to understand the implementation before using the product. A task-oriented surface starts with image creation, video creation, editing, or production tools, and then makes model choice visible where it helps.
SceneFlare still has a model directory. Hiding model identity would make comparison harder, especially when input modes and output controls differ. But the model is presented as part of a workflow, not as the entire workflow.
The useful question is not only, "Which model is best?"
It is, "Which configured workflow accepts the material I have and produces the asset I need?"
Image and video models rarely expose the same shape.
One image model may support text-to-image and reference editing. Another may add transparent output or custom dimensions. A video model may accept a starting image, multiple references, source video, audio, or some combination of them. Duration and resolution options can change again between models.
If every page speaks the provider's language directly, the product becomes a collection of unrelated forms.
I prefer a product-owned vocabulary:
The internal model catalog maps that vocabulary to each model's real capabilities. The interface can stay consistent without pretending that all models are identical.
This is an important distinction. Consistency does not mean flattening every difference. It means giving each difference one predictable place.
A prompt is simple: it is text that can be validated and sent with a request.
Reference-led creation is less simple.
The product has to know how many assets a mode accepts, which media types are valid, whether order matters, whether a video duration affects cost, and whether an uploaded image is a reference, a mask, or the primary input.
That is why I do not think of upload as a generic attachment feature. Source assets are typed inputs to a creative operation.
The form should prevent impossible combinations early. The server should validate the same rules again. A stale tab or a direct request should not be able to submit something the selected model cannot process.
The browser is useful for feedback. The server is responsible for the contract.
Pricing an AI media task is not always a flat lookup.
An image request may depend on quality, output size, prompt length, reference count, or number of outputs. A video request may depend on duration, resolution, audio, and source media. Provider prices can also change while old tasks still need an understandable billing history.
The safest point to resolve the product price is before the task enters the generation pipeline.
The flow becomes:
normalize input
|
v
calculate and show credit quote
|
v
confirm the request
|
v
freeze the quoted cost and queue the task
The UI estimate and the server charge must come from the same pricing rules, but the server still performs the authoritative calculation.
A later tariff update should not silently change the cost of a task the user already confirmed. Persisting the pricing snapshot is not only an accounting decision. It is a trust decision.
Image generation can be slow. Video generation makes this impossible to ignore.
Once a provider accepts a task, several things can happen:
A request handler should not pretend all of this is one long synchronous function.
The user-visible task needs a durable state: pending, processing, completed, or failed. Provider attempts need their own history. Results need deterministic storage identities. Settlement needs to be safe to repeat.
The uncomfortable case is an ambiguous submission. If the provider may have accepted the job but the local request timed out, immediately trying another provider can create two paid jobs. "Unknown" is a real state, even if it is not a pleasant one.
Retries are easy to add. Correct retry boundaries are the actual work.
A generated URL is not the final product experience.
Provider URLs may expire. One request may return several outputs. A user may want to compare a result, download it later, or reuse it as the source for another workflow.
SceneFlare treats completed generations as assets in a library rather than temporary responses on a form. The image and video workflows may start differently, but their results should enter a familiar place with consistent status and download behavior.
This also changes the backend boundary. Provider adapters should return normalized source results. Product storage should decide where final assets live. The adapter should not own the user's library structure.
Provider integration and product ownership are related, but they are not the same responsibility.
Prompt checks alone are not enough for an AI media product.
A harmless prompt can include an unsafe reference image. A safe input can produce an output that violates policy. A video can contain a problematic moment that is easy to miss if only one frame is inspected.
Safety therefore belongs at more than one boundary:
A provider saying "completed" means the model finished. It does not necessarily mean the product is ready to publish the result.
That difference is small in a diagram and important in production.
The infrastructure behind a multi-model product can become complicated. The interface should not celebrate that complexity.
The user needs to understand:
Everything else is an implementation detail until it helps answer one of those questions.
That is the principle I keep returning to while working on SceneFlare. The platform can support prompt-based images, reference editing, text-to-video, image-to-video, background removal, upscaling, and new model families. The experience should still feel like one product.
It is tempting to describe an AI creation platform by listing its models.
The more useful description is the system around them.
The catalog explains what each model can do. The form translates capabilities into valid choices. The quote makes cost explicit. The queue separates user requests from slow execution. The workflow handles uncertain provider states. Moderation protects the input and the result. The library turns a response into a reusable asset.
The model creates the media.
The product makes the creation process understandable and dependable.
That is the part I am building with SceneFlare, and it is the part that becomes more important every time another model is added.