NAWA Studio / Selected work

Three live systems. One method.

Real briefs, honest statuses, and a difference you can verify: our systems are not slideware — they are deployed, and you can open every one of them right now.

2products live — in production or open beta

1voice agent answering on this site right now

8free guides and sparks in the library

4solution ecosystems, one studio method

Fashion Retail · YafaWear

A store that thinks

In production

YafaWear live storefront homepage — Real product screenshot — live storefront, July 2026

The challenge

An independent boutique competing with global platforms needs studio-grade content, instant customer help, and buying confidence — without a big team.

Before

Manual photo production for every drop, slow answers to customers, and a storefront that behaved like a static catalog.

With NAWA Studio

“Layan” — an Arabic voice + chat assistant that guides customers and takes orders
Virtual try-on and image-based product search
A recommendation engine across collections
Generative, brand-consistent product and campaign imagery
A full Arabic commerce core: promotions, ratings, PayPlus, WhatsApp

The outcome

Live in production at yafawear.com, serving customers daily — content, assistance, and commerce operating as one connected system.

Read the case study →Visit the live store ↗

Generative Commerce · VOGO Vision AI

One photo becomes a campaign

Working product · private beta

VOGO Vision AI studio — live sign-in screen — Real product screenshot — live studio, July 2026

The challenge

Campaign photography is the biggest recurring content cost in fashion — every drop demands studios, models, and weeks of production.

Before

A physical shoot for each collection, or inconsistent freelance visuals that drift off-brand.

With NAWA Studio

Upload one garment photo — Gemini Vision analyzes cut, fabric, and styling
Cast reusable virtual models in the model studio
Generate photoshoots, collection lookbooks, and footwear campaigns
Extend selected visuals to short fashion films (Kling video via kie.ai)
Accounts, credit ledger, archive, and an admin console built in

The outcome

A working studio in private beta — deployed, live, and open: visitors can create an account and try the pipeline today.

About the product →Launch VOGO Studio ↗

Voice AI · Kamel's Virtual Assistant

A founder who answers at 3am

Live on this site

The live voice assistant page on this site — Real product screenshot — this website, July 2026

The challenge

Visitors want real answers about the work — in Arabic or English, at any hour — not a brochure and a contact form.

Before

A static portfolio where every question waited for an email reply.

With NAWA Studio

An ElevenLabs conversational agent speaking with Kamel's cloned voice
Live WebRTC calls straight from the browser — no app, no signup
A curated knowledge base: verified facts and honest project statuses only
Consent-based lead capture wired to the studio's own database
The same architecture running Layan's voice ordering in production

The outcome

Running live on every page of this site — press the mic button and have the conversation right now.

Meet the assistant →

Engineering decisions

The reasoning, including the wrong turns.

Screenshots show what was built. These show why it was built that way — six decisions taken while building this site and the systems on it, each with what it cost. Two of them are mistakes that reached production before they were caught.

Long generations

Problem

Teacher Studio kept being reported as broken, but every API call passed when tested with curl. Reproducing it in a real headless browser showed why: generation ran inside one HTTP request lasting 40–90 seconds, and the browser dropped the connection at ~37s with ERR_NETWORK_CHANGED. The server had done the work; the answer had nowhere to land.

Decision

A job queue. The POST now writes a row to `teacher_jobs` and returns a job id in about a second; the real work runs in Next's `after()` hook and the client polls every 3 seconds with staged progress. Cloud Run needs --no-cpu-throttling and --timeout=300 for post-response work to finish at all.

Trade-off

More moving parts than a single request, and a table to maintain. In exchange, a locked phone screen or a network handover no longer destroys a generation that already ran. Spark Studio and Brand Studio were moved onto the same pipeline.

Model providers

Problem

A tool that calls one model directly dies the moment that model is renamed, rate-limited, or removed — and model names churn constantly. Several names that worked one week returned 404 the next.

Decision

One internal interface in `lib/ai/` with an ordered provider chain: Gemini 3.1 Pro on kie's per-model route first, then DeepSeek, then a reasoner retry, and a deterministic template if every provider is down. Each attempt is logged to `model_requests` with provider, model, duration, and status.

Trade-off

An abstraction layer to maintain, and the newest provider-specific feature is never available on day one. In exchange the tools survive provider outages, and swapping the primary model is one environment variable — the change that took Teacher Studio from 45s to 16s.

Configuration

Problem

Setting KIE_TEXT_MODEL on Cloud Run to fix one tool instantly broke another with 502s. Two subsystems had grown to read the same variable for different routes: Spark's per-model path and the shared router's chat path.

Decision

Give each subsystem its own variable — the router reads KIE_CHAT_MODEL and never inherits Spark's. Documented in docs/11 as a trap, because the failure mode was invisible: nothing logged a conflict, one tool simply started returning 502 immediately.

Trade-off

Two variables where one looked sufficient. Shared configuration between subsystems that evolve separately is a silent coupling, and this one cost a live outage to find.

Media delivery

Problem

42 campaign films are far too heavy to ship inside an application image, and a commit once carried 1.7GB of raw video into git before it was caught and rebuilt.

Decision

The films live in a public Cloud Storage bucket with a manifest read at runtime. Adding work is a script run plus an rsync — no rebuild, no redeploy. The raw footage is excluded in both .gitignore and .gcloudignore, so neither git nor the build upload can pick it up again.

Trade-off

The gallery depends on a bucket being reachable, so the page degrades to an honest empty state rather than an error. Worth it: publishing new work no longer requires a developer.

Cost control

Problem

Free image generation costs real money per run. Left open, a single enthusiastic afternoon could produce a bill nobody planned for.

Decision

Daily per-visitor limits counted from the existing `model_requests` log against a hashed IP, rather than adding a quota table. The usage record needed for cost tracking was already being written; counting it was free.

Trade-off

A hashed IP is a weak identity — shared networks share a quota, and it is not a hard guarantee. Accepted deliberately: the alternative was forcing every teacher to create an account, which would have cost more usage than the abuse it prevented.

Bilingual delivery

Problem

Storing the language in React state alone means the server sends English first and the page visibly flips after hydration. On an Arabic-first site that is the first thing a visitor sees.

Decision

The choice lives in a cookie the server layout reads, so `<html lang dir>` and every string are correct in the first byte.

Trade-off

Reading cookies opts every page out of static rendering. The subtler cost showed up immediately: the cookie name was first defined in a `"use client"` module, and every export of such a file becomes a client reference on the server — so the layout compared the cookie against a proxy, never matched, and served English to everyone. Types passed, the build passed, and only a behavioural test caught it. The constant now lives in a neutral module.

Every brand has its own bottleneck. Let's find yours.

Start a project ↗