The backend path behind an AI visual-generation product: request intake, job lifecycle, model/provider boundaries, GPU workers, live progress, storage, and release workflows.
AI product backend · workflows · model APIs · deployment2025-presentnover.studio ↗
SUMMARY
Backend and AI infrastructure for Nover's visual-generation platform: APIs, Redis job orchestration, WebSocket delivery, GPU inference on AWS, output storage, and deployment paths.
Problem
AI generation is a distributed workflow, not a single model call. Requests need state, progress, retries, file handling, cost boundaries, and a UI that can explain what is happening while work runs.
What I built
I contribute to the backend and AI product infrastructure around generation workflows, model/provider boundaries, job lifecycle, WebSocket delivery, GPU execution, and deployment paths. Product-internal details stay private while Nover is still early-stage.
Architecture / system design
The public shape is API entry points, workflow state, model/provider integration, worker execution, file handling, and deployment surfaces wrapped so product features are not coupled directly to any one model vendor.
Failure modes / what broke
The recurring failure class is ambiguity around long-running AI work: latency, retry state, cost control, model/provider errors, and progress reporting all have to be legible instead of mysterious.
Proof / metrics / tests
Public proof is intentionally bounded because implementation details are private. The case study shows the infrastructure shape while keeping model and product internals private.
Lessons learned
The model is the easiest part to swap. The durable work is job lifecycle, UX state, provider boundaries, cost control, and failures that support people can actually reason about.
AI generation is not just a model call. It is a distributed workflow: API requests, job state, queues,
workers, retries, file handling, progress updates, cost limits, latency, model/API boundaries, and failure
recovery. The model is one piece — the system around it is what decides whether users experience the
product as a reliable tool or as a black box that sometimes works.
What this role actually is. I'm a founding engineer at Nover - not the owner, not the
sole builder. I contribute to the backend and AI product infrastructure: the generation workflows behind
the visual tool, the surrounding job lifecycle, model/API orchestration, and the deployment paths that
ship it. Other people own other parts of the stack; this page describes my part.
Some implementation details are kept private while the product is early-stage, but the public engineering shape
is clear enough to describe. These are the three areas I work across:
Specific prompts, model identities, and product-internal details kept private during early-stage development
01 · Generation workflows
Backend systems behind the visual tool
The path from a user request to a finished asset is not a single function call. It is a chain: queueing,
workers, model/API integration, retries, file handling, and progress reporting back to the UI. The work
I contribute to lives in that chain.
02 · Product backend & deployment
State the user actually sees
Job state, account/billing-adjacent flows, and the deployment paths that get all of it to production.
"Real-time" only feels real-time if the backend agrees with the UI about what is happening - which sounds
obvious until you watch it stop being true under load.
03 · Model / API orchestration
Integrating generation behind a stable surface
Wrapping model and provider APIs behind interfaces the rest of the product can rely on: cost-aware
calls, latency-aware fallbacks, retries with idempotency, and clear failure shapes so something useful
happens instead of the request silently dying.
THE GENERATION PATH
From a request to a finished asset, generation runs as a distributed pipeline - the part of the system
that decides whether the product feels like a tool or a black box.
fig. — request → queue → GPU worker → model → CDN, with progress streamed back to the UI over
WebSockets. Product internals stay private; the public engineering shape does not.
hover or tab through any stage to trace the pipeline
LESSON LEARNED
The biggest thing Nover has taught me is that AI product engineering is not really about the model. The
model is the easy part to swap. The hard part is everything around it: job lifecycle, cost control,
retries, UX state, prompt/model boundaries, file handling, and making failures legible instead of
mysterious. Get that wrong and a working model still feels broken; get it right and even an imperfect
model feels like a tool.
contact
Open to backend systems, AI infrastructure, and product engineering roles.