DEV Community: Natalia

An AI Creation Product Is More Than a Model Picker

Natalia — Sat, 12 Sep 2026 01:33:58 +0000

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:

turn a product photo into an ad concept
animate a still image
create several campaign directions
remove a background before publishing
improve an asset that is too small for its final placement

The product has to translate that intent into a reliable generation workflow. The model call is only one step inside it.

Start With the Job, Not the Model

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?"

Different Models Need One Product Language

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:

mode describes the creative transformation
source assets describe the material supplied by the user
fields describe supported choices such as aspect ratio, duration, or quality
outputs describe the assets returned to the user
credits describe the price confirmed before submission

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.

Source Assets Are Part of the Request

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.

Quote Before You Queue

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.

Generation Is an Asynchronous State Machine

Image generation can be slow. Video generation makes this impossible to ignore.

Once a provider accepts a task, several things can happen:

the result arrives through a callback
polling observes completion first
a timeout occurs after the provider accepted the request
the provider returns multiple outputs
an output transfer fails after generation succeeded
moderation or final settlement needs to be retried

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.

The Result Should Become an Asset

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.

Safety Has to Follow the Whole Workflow

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:

validate the prompt and request before spending generation credits
inspect uploaded source assets where the workflow requires it
inspect generated outputs before making them available
keep the final business transition separate from the provider's success signal

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.

Keep the Interface Boring

The infrastructure behind a multi-model product can become complicated. The interface should not celebrate that complexity.

The user needs to understand:

what they can create
which inputs are required
what each control changes
what the task will cost
whether the task is waiting, running, complete, or failed
where the result goes next

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.

The Product Is the Orchestration

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.

A Model Catalog Is the Missing Product Contract in Multi-Model AI Apps

Natalia — Fri, 24 Jul 2026 04:14:46 +0000

The first AI model in a product rarely creates an architecture problem.

You build a form, call an API, and display a result.

The second model adds a dropdown and a few conditions. The third adds another input mode. Before long, the product supports text-to-image, image-to-image, text-to-video, image-to-video, reference-based generation, video editing, background removal, and upscaling.

At that point, calling the provider is no longer the hardest part.

The difficult questions are product questions:

Which modes does each model support?
Which controls should the form render?
How many reference assets can a user upload?
Does the model accept images, video, audio, or a combination?
Which parameter combinations are valid?
How does resolution, duration, or source media affect the credit cost?
Can the provider rename a model without breaking public URLs or stored tasks?

While building AI Image Editor, I found that a provider adapter only solves part of this problem. The application also needs a model catalog above the adapter: one product-owned contract describing what every model means inside the product.

Provider Adapters Answer the Wrong Question

A provider adapter is still useful. It can normalize operations such as:

interface GenerationProvider {
  submit(input: ProviderInput): Promise<ProviderJob>
  getStatus(jobId: string): Promise<ProviderResult>
}

The rest of the application does not need to care whether one provider calls an identifier taskId and another calls it predictionId.

But an adapter answers, "How do I call this service?"

It does not answer, "What should this product allow the user to do?"

One provider can expose many models with completely different product rules. One image model may accept 16 reference images, while another accepts four. One video model may accept video input, while another only accepts a starting image. Some models charge by resolution. Others charge by output duration or by both input and output media.

Those differences belong to the product layer.

Describe Capabilities as Data

A useful catalog entry can look like this:

type ModelCatalogEntry = {
  id: string
  kind: 'image' | 'video'
  slug: string
  modes: Array<{
    id: string
    supportsReferenceAssets: boolean
  }>
  fields: Array<{
    id: string
    options: Array<{ label: string; value: string }>
  }>
  defaults: Record<string, string>
  maxReferenceAssets: number
  sourceAssetAccept?: string
  creditCost: CreditCostTier[]
  providerRoutes: ProviderRoute[]
}

This object is not a copy of a provider response. It is the application's own definition of the model.

The internal id and public slug belong to the product. A provider-specific model name belongs inside providerRoutes. If an integration changes later, the application should not have to rewrite database history, public page URLs, and frontend state.

Product identity should be stable. Provider identity should be replaceable.

Generate the Form From Capabilities

Without a catalog, model forms often become a growing collection of conditions:

if (model === 'model-a') {
  showResolution()
}

if (model === 'model-b' || model === 'model-c') {
  allowReferenceImages()
}

This feels direct while the catalog is small. It becomes fragile when models are renamed, upgraded, or share only some capabilities.

A capability-driven form reads the entry instead:

modes renders text-to-image, image-to-image, or video-edit tabs
fields renders resolution, aspect ratio, duration, and audio controls
defaults initializes the form
maxReferenceAssets controls the uploader
sourceAssetAccept limits media types

Adding a model becomes primarily a data change, followed by contract tests, instead of a search for every component that knows the model name.

The frontend also stays deliberately boring. It renders product capabilities without learning provider terminology.

Enforce the Same Contract on the Server

Generating the UI from a catalog is not enough. If the server does not use the same rules, the catalog is display configuration rather than a contract.

After receiving a request, the server should check:

The model exists and matches the requested media kind.
The requested mode belongs to the model.
The selected mode accepts the supplied references.
The number and kinds of assets are allowed.
Dynamic fields contain only declared values.
Cross-field combinations are compatible.

The server cannot trust the rendered form. A request may come from a stale browser tab, an older deployment, or a client calling the endpoint directly.

The safer flow is:

request schema
    |
    v
model catalog normalization
    |
    v
credit calculation
    |
    v
persist normalized task

The worker then receives normalized product input rather than raw form state.

Pricing Belongs in the Contract Too

A flat "10 credits per generation" rule rarely survives a multi-model product.

Image cost may depend on resolution. Video cost may depend on duration, quality, audio, and whether the user supplied video input. Provider pricing also changes over time.

Catalog pricing can be expressed as versioned matching rules:

type CreditCostTier = {
  credits: number
  effectiveAt: string
  resolution?: string
  duration?: string
  withAudio?: boolean
  withVideoInput?: boolean
}

The resolver first chooses the latest price version effective at the task creation time. It then selects the most specific tier matching the normalized input.

Two details matter here.

First, calculate and persist the cost before the task enters the generation pipeline. A price update while the task is waiting should not change what the user already confirmed.

Second, the UI estimate and server charge should use the same resolver. A price displayed on a button and a different price recorded in billing is a fast way to lose trust.

Test Catalog Semantics, Not Only Types

TypeScript can validate the shape of an entry. It cannot prove that the entry makes sense.

A correctly typed configuration can still contain:

a default value missing from its options
a duplicate public slug
an uncovered resolution-duration price combination
a reference-enabled mode with a zero reference limit
a provider route pointing at the wrong media kind
a new price version that unintentionally changes historical calculations

The catalog deserves focused tests:

every default is an allowed option
every public slug is unique
every supported mode normalizes successfully
every price combination resolves deterministically
every provider route matches the model kind

These tests also make reviews clearer. A model integration becomes a visible declaration of capabilities instead of a trail of special cases across unrelated files.

Do Not Turn Everything Into JSON

A catalog does not mean every difference must be forced into static configuration.

Some models have real cross-field constraints. Some video prices depend on the measured duration of uploaded source assets. Those rules are easier to express as explicit pure functions called through the catalog's public API.

A practical boundary is:

capabilities, options, defaults, and routes are data
normalization, cross-field validation, and dynamic cost are pure functions
request translation and response parsing stay in provider adapters
retries and final settlement stay in the job workflow

The goal is not to eliminate code. It is to give every difference one authoritative home.

The Payoff Is Predictability

The complexity of a multi-model AI product does not come from the number of API clients. It comes from the number of capability combinations crossing the same product flow.

Provider adapters hide integration differences. A model catalog gives the rest of the application one consistent interpretation of those differences.

Once the catalog becomes a real product contract, adding a model stops meaning "add another exception everywhere." It becomes "declare a new set of capabilities inside a boundary we already understand."

That predictability is more valuable than saving a few minutes on the next integration.

Notes on Configuring TanStack Start for Cloudflare Workers

Natalia — Thu, 04 Jun 2026 08:11:55 +0000

I like frameworks that make the boring parts stay boring.

For an AI image website like Flux 2, the frontend is only one slice of the work. There are landing pages, account flows, uploads, generation history, admin screens, and a lot of small server-side decisions around performance and reliability. That is why TanStack Start on Cloudflare Workers is interesting: Vite-based development, full-stack routing, server functions, static assets, and an edge runtime can all fit into one deployment story.

The part I care about most is not the headline feature list. It is the config.

If the config is clear, the team knows what gets deployed, where it runs, and which runtime assumptions the app is making. If the config is messy, every release feels a little suspicious.

This is the short version of how I would approach a TanStack Start + Cloudflare setup.

Start with the Cloudflare target in mind

TanStack Start can run on different hosting targets, but Cloudflare Workers has a specific shape. The official Cloudflare TanStack Start guide shows two useful paths:

create a new app already configured for Cloudflare
adapt an existing TanStack Start app by adding Wrangler and the Cloudflare Vite plugin

For a new project, I would rather start with the Cloudflare path than retrofit it later:

pnpm create cloudflare@latest my-app --framework=tanstack-start

For an existing project, the main idea is simple: TanStack Start still uses Vite, but the Cloudflare plugin needs to participate in the server-side build.

The Vite config is the first file I check

The Vite config tells me whether the project is actually being built for the runtime I expect.

A Cloudflare-oriented setup usually looks like this:

import { cloudflare } from "@cloudflare/vite-plugin";
import { tanstackStart } from "@tanstack/react-start/plugin/vite";
import react from "@vitejs/plugin-react";
import { defineConfig } from "vite";

export default defineConfig({
  plugins: [
    cloudflare({ viteEnvironment: { name: "ssr" } }),
    tanstackStart(),
    react(),
  ],
});

The important part is not memorizing every line. The important part is that the SSR environment is intentionally wired through Cloudflare. That keeps the server side of the app close to the Worker runtime instead of accidentally drifting toward a generic Node.js assumption.

That matters when the app grows. Server functions, route loaders, auth checks, media metadata, and dashboard requests are all easier to reason about when the runtime is explicit.

Wrangler config should be small at first

The next file I look at is wrangler.jsonc.

I prefer starting small:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "example-tanstack-start",
  "compatibility_date": "2026-06-04",
  "compatibility_flags": ["nodejs_compat"],
  "main": "@tanstack/react-start/server-entry",
  "observability": {
    "enabled": true
  }
}

This does a few useful things.

main points Wrangler at the TanStack Start server entry. compatibility_date makes the Workers runtime version explicit. nodejs_compat gives the app a more practical compatibility baseline for packages that expect some Node APIs. observability makes the first round of debugging less blind.

I do not like stuffing this file with every future binding on day one. The config should grow when the product needs it.

Add scripts that explain the workflow

The package.json scripts should make the common path obvious:

{
  "scripts": {
    "dev": "vite dev",
    "build": "vite build",
    "preview": "vite preview",
    "deploy": "pnpm build && wrangler deploy",
    "cf-typegen": "wrangler types"
  }
}

I like this because it separates concerns:

dev is for local development
build proves the app can compile
preview lets me inspect the built result
deploy keeps the build step attached to release
cf-typegen keeps Worker bindings typed

The last one is easy to skip, but it is useful once bindings enter the project. A typed env is much better than guessing whether a binding name is available in a server function.

Treat bindings as product decisions

For a real AI image product, Cloudflare bindings can become important quickly.

You might use R2 for generated media, D1 for lightweight relational data, KV for low-risk cache data, Queues for background jobs, or a service binding for splitting a larger backend into smaller Workers.

But I try not to add bindings just because the platform supports them. I add them when a workflow needs a clear ownership boundary.

For example, an upload or generated asset flow may justify an R2 binding. A scheduled cleanup job may justify a custom entrypoint. A separate auth or billing service may justify a service binding. The config should tell that story plainly.

Inside TanStack Start server code, Cloudflare bindings are accessed through the Worker environment. That is a good fit for server functions because browser code does not need to know about storage buckets, queues, or internal services.

Be careful with prerendering

TanStack Start can prerender routes, and Cloudflare can serve static assets efficiently. That is useful for pages that do not depend on per-user state.

I would consider prerendering for:

marketing pages
documentation-style pages
static comparison pages
content that changes on a predictable schedule

I would not use it blindly for account pages, generation history, payment status, or anything that depends on a signed-in user.

The trap is not prerendering itself. The trap is forgetting when data is read. Build-time data and request-time data are different. Once that distinction is clear, prerendering becomes a useful tool instead of a source of confusing stale pages.

Keep environments boring

I want staging and production to be boringly explicit.

That usually means separate Worker names and routes, with the same general structure:

{
  "env": {
    "staging": {
      "name": "example-tanstack-start-staging"
    },
    "production": {
      "name": "example-tanstack-start-production"
    }
  }
}

Then commands become hard to misread:

pnpm build
wrangler deploy --env staging --dry-run
wrangler deploy --env staging
wrangler tail --env staging

wrangler deploy --env production --dry-run
wrangler deploy --env production
wrangler tail --env production

The tail step is not glamorous, but it is one of the fastest ways to notice obvious runtime mistakes after a release.

The config is part of the product

For a TanStack Start app on Cloudflare, I think of configuration as product infrastructure, not boilerplate.

The Vite config says how the app is built. The Wrangler config says how it runs. The scripts say how developers interact with it. Bindings say which Cloudflare resources the app depends on. Environment sections say where a release is going.

That is why I prefer a small, readable setup over a clever one.

For an AI image website, the product can be complex enough already. The deployment path should be easy to inspect: TanStack Start for the app shape, Cloudflare Workers for the runtime, Wrangler for the release workflow, and only the bindings the product actually needs.

Why AI Image Generation Should Be Async

Natalia — Fri, 29 May 2026 04:33:18 +0000

AI image generation can look like a simple request-response feature.

A user enters a prompt, clicks generate, and waits for an image.

For a prototype, that can work. For a production product, it usually becomes fragile.

Image generation may take several seconds or minutes. A provider may return a job ID first and the final result later. Some results arrive through webhooks. Others need polling. Requests can fail, time out, or finish after the user has already left the page.

That is why AI image generation is usually better designed as an asynchronous workflow.

This is the approach I use while building Image 2, a multi-model AI image generation and editing platform.

The Simple Version

The most direct implementation looks like this:

User -> API route -> AI provider -> result -> user

This is easy to understand, but it has several problems:

the HTTP request may time out
retries can create duplicate jobs
the frontend depends on provider latency
billing or credit logic becomes harder to protect
generated media may live on temporary provider URLs
failures are difficult to repair after the request ends

This pattern is fine for demos. It is not ideal once real users, payments, storage, and retries are involved.

A Better Shape

A more reliable version separates the user request from the generation work:

User request
  |
  v
Create generation record
  |
  v
Push message to queue
  |
  v
Background worker submits job
  |
  v
Webhook or polling gets result
  |
  v
Store asset and update status

The user-facing request returns quickly after creating the task. The UI can then show a status such as queued, processing, completed, or failed.

The slow work happens in the background.

Why Async Helps

Async generation gives the system more room to recover.

If the provider is slow, the task can remain in processing.

If the provider fails, the system can mark the task as failed and roll back credits.

If a webhook is missed, a scheduled job can poll the provider later.

If both a webhook and a polling job see the same final result, the system can ignore duplicate settlement.

That last point matters. In production, the same generation result may be observed more than once. Final states such as completed and failed should be idempotent.

A Small State Model

You do not need a complicated state machine to start. A simple model is often enough:

created -> queued -> processing -> completed
                         |
                         -> failed

Each state should mean something clear:

created: the request was accepted
queued: background work has been scheduled
processing: the provider job has started
completed: the final asset is available
failed: the task cannot complete

The important rule is that terminal states should be protected. Once a task is completed or failed, retries and duplicate callbacks should not apply the same result again.

Store the Result Yourself

Many AI providers return a URL for the generated image. That URL may be temporary or provider-controlled.

For a real product, it is often safer to copy the result into your own storage:

Provider result URL -> app storage -> stable asset URL

On Cloudflare, that might mean storing the final image in R2 and serving it from your own CDN domain.

This makes future product behavior easier:

user ownership checks
downloads
cleanup
moderation
stable previews
billing history

The AI provider creates the image. Your application should own the product workflow around that image.

Where Multi-Model Apps Get More Complex

Async workflows become even more useful when an app supports more than one model or generation style.

A text-to-image model, an image editing model, and a reference-image workflow may all behave differently. Some may return results quickly. Others may need a provider-side job ID. Some may support high-resolution output. Some may have different input limits.

A product like Image 2 can expose those workflows through a simpler user interface while keeping provider-specific details in the backend. For example, separate pages such as the GPT Images 2.0 image generator or the Nano Banana 2 AI image generator can still share the same general task lifecycle.

That is the main benefit of designing around the workflow instead of designing around one provider API.

Final Thought

AI image generation is not just a model call. It is a product workflow.

For experiments, a synchronous API route is enough. For production, async architecture gives you a cleaner way to handle slow jobs, duplicate callbacks, retries, storage, moderation, and credit accounting.

The model creates the image. The workflow makes the product reliable.