Static Ad Production Studio by Ugo ChukwuStatic Ad Production Studio by Ugo Chukwu

Static Ad Production Studio

Ugo Chukwu

Completed work

AI Agent Engineer

AI Developer

AI Engineer

Python

React

TypeScript

Advertising

Static Creative Studio — Engineering the Workflow Around Image Generation

Role: Founding Lead Engineer Company context: Peerless Public reconstruction: Static Creative Studio by Etherlabs Repository: https://github.com/Etherlabs-dev/static-creative-studio Live deterministic UI: https://static-creative-studio.vercel.app

A fresh, sanitized reconstruction of static-creative systems I designed and built during my work for Peerless. The public product uses new code, fictional organizations, synthetic assets, and no proprietary prompts, production credentials, client identities, or live advertising actions.

The outcome

I designed and built a full-stack static-ad production workspace that preserves the parts image-generation demos usually lose: approved strategy, exact copy, supported claims, asset roles, immutable version lineage, spatial feedback, reviewer authority, and the identity of the artifact actually approved.

A creative lead can compare versions, attach normalized feedback to a precise image region, resolve it into a child version, and submit one exact artifact. A brand reviewer can approve or reject that version. The system then creates an idempotent multi-placement manifest while explicitly recording published: false.

Northstar Athletics, its campaign, product imagery, offer, claims, feedback, and outputs are synthetic.

The real problem was not generating pixels

A polished image can still be operationally unsafe. Copy may drift from the approved brief. A claim may have no evidence. Feedback may refer to an overwritten file. A reviewer may approve “the project” while the creative lead is looking at a different version. A packaging step may silently become publishing.

The product therefore treats generation as one bounded component inside a governed creative lifecycle.

My role

As Founding Lead Engineer at Peerless, I owned product and system architecture, prioritization, full-stack delivery, testing, production iteration, client workflow delivery, and later technical direction. I was the sole engineer through July 2026 before the engineering team expanded.

For this subsystem, the work included translating strategy into a stable creative contract, defining immutable version and annotation models, separating creative-lead and reviewer authority, implementing deterministic safety gates, and establishing a safe boundary before external advertising execution.

System architecture

The public reconstruction uses React, Vite, and TypeScript for the responsive studio, with FastAPI, Pydantic, and SQLite implementing the durable workflow contract. Signed synthetic sessions establish tenant and role scope. OpenAPI is generated from the API.

The deterministic frontend allows evaluators to inspect the main workflow without a paid image provider. The backend independently proves durable state, authorization, concurrency, lineage, and packaging behavior.

Strategy before generation

Exact copy, offer, audience, angle, palette, typography, safe claims, and source-asset roles remain visible beside the creative. They are product inputs—not invisible prompt decoration.

Deterministic code verifies copy equality, prohibited claims, annotation geometry, placement dimensions, review state, and packaging identity. A future provider can generate pixels behind the version contract, but cannot bypass those checks.

Immutable versions instead of overwritten files

Every correction creates a child version with a parent identifier and a new checksum. The source artifact remains intact. Feedback remains attached to the version on which it was drawn.

Optimistic concurrency rejects stale callers instead of silently overwriting newer work.

This transforms version history from filename convention into enforceable product state.

Region feedback becomes structured data

Review annotations use normalized coordinates so they survive different screen and image sizes. Rectangles must be positive and fully bounded. Each item includes a category, comment, author, state, and version identity.

Resolving feedback produces a new version rather than mutating the reviewed image. The original comment, region, and artifact remain attributable.

Tenant and role boundaries

Creative leads can annotate, create child versions, and submit an exact version.

Brand reviewers can approve, reject, or request changes on the submitted version.

Neither role can access another tenant.

Cross-tenant identifiers return 404 without exposing record existence.

The API enforces these boundaries; disabled interface controls are not the security mechanism.

Approval is not publishing

Packaging requires the active approved version and is unique for the project-version pair. Repeating the request returns the existing manifest.

The output records placements for 4:5, 1:1, and 9:16 and always retains published: false. There is no ad-account connection, publisher credential, campaign launch, webhook, or billing integration.

Verification

The August 11, 2026 publication checkpoint includes:

6 passing web interaction and keyboard tests;

11 passing API and negative-security tests;

8/8 deterministic evaluations;

two consecutive reset/migration runs;

passing lint, Ruff, production build, dependency audits, secret scan, and local health/OpenAPI smoke;

desktop and mobile browser acceptance with zero observed console warnings or errors; and

GitHub Actions run 31530377933, passing both jobs at commit e0870f7.

The personally owned deterministic frontend is live at static-creative-studio.vercel.app. HTTP returned 200, and hosted desktop comparison, reviewer-role selection, exact-version approval, and no-publishing confirmation passed. The API and SQLite workflow remain local; this is not a live provider or advertising deployment.

What the evaluations prove

The evaluations check exact copy, supported claims, bounded annotations, immutable lineage, review state, approved-version identity, placement dimensions, and the non-publishing boundary. They test workflow invariants—not artistic quality, campaign performance, or image-provider accuracy.

Failure behavior

The safe path is intentionally strict:

Missing or tampered authentication returns 401.

Cross-tenant identifiers return 404.

Wrong-role mutations return 403.

Stale project versions return 409.

Invalid or out-of-bounds annotation geometry is rejected.

Open feedback blocks the review transition.

A reviewer cannot approve the wrong state or an old artifact.

Packaging cannot proceed unless the active version is the approved version.

These states are product behavior, not exceptional logs. They give users a precise recovery path without letting the system guess what they intended.

Historical engineering context

A dated private-source review confirmed an active Peerless static-creative workflow spanning strategy-grounded briefs, reference controls, shared image generation, quality gates, child versions, region annotations, comparison, structured review, rejection sanitization, approval, and placement packaging.

That evidence supports the architectural story and my role. Proprietary prompts, private assets, internal names, client data, and unsupported performance claims remain excluded.

Mobile review

Mobile deliberately stages Projects, Creative, and Review as separate thumb-friendly states. The reviewer sees deterministic checks, placement selection, open-feedback count, the exact locked version, and the explicit no-publishing boundary.

What I learned

The hard part of creative AI is not producing another image. It is maintaining truth across strategy, pixels, feedback, lineage, approval, and delivery.

The system became safer and easier to reason about when deterministic facts stayed in code, every correction created a child, spatial feedback became durable data, approval targeted an exact checksum, and packaging stopped before external execution.