Yula.ai

Problem

Yula was building an AI customer-service product for Shopify stores. The product behavior, simplified: an incoming customer email is categorized, looked up against a knowledge base scraped from the store’s own site, drafted into a reply, self-verified by a second agent, and then either sent or rewritten (up to three attempts before bailing out). The MVP needed the public surface: landing, sign-up, plan selection, store configuration (business domain, customer-service signature), and a “Generate an answer” preview where operators could test the agent against a paste-in email before pointing it at their real inbox.

The backend was non-trivial: a FastAPI service wrapping a LangGraph agent flow, Pinecone vector store with namespace-per-store for multi-tenancy, Redis-backed job queues with a dead-letter queue and retry counters, Gmail integration, Clerk auth. My job was the frontend that made the whole thing feel usable in three months on Heroku.

Approach

The product had two surfaces in one codebase: a public-facing landing and sign-up funnel at yula.ai, and a Shopify embedded app where store operators configure their domain, signature, and preview agent runs from inside the Shopify admin itself. I built both as a single Remix project — Remix is the stack Shopify recommends for embedded apps via @shopify/shopify-app-remix, and folding the marketing site into the same project meant one deploy, one Prisma+Postgres for shop state, and a unified handling of two auth surfaces (Clerk for the off-Shopify sign-up funnel; Shopify OAuth on the embedded side).

The frontend split its work intentionally across three layers:

1. Remix loaders (server-side, SSR) handled the fast SSR reads — Clerk auth, shop state from Prisma — so the dashboard rendered hydrated.
2. A Remix action (/api/processEmail) took on the short server-side write — a Prisma upsert that decided whether the store’s content needed re-scraping — and returned in a single quick response.
3. The browser-side React component then orchestrated the actual long-running work: it called the FastAPI backend’s /scrape and /email endpoints directly and polled their status every five seconds in a while loop, all in the browser.

The non-obvious UI call sits in that third layer: the trigger button itself is the live status surface. There’s no separate spinner, no progress bar, no toast — when the operator clicks Generate an answer, the button’s own text mutates through the task lifecycle: On queue… → Collecting website content… → Writing the email for you… → Retrying… → Email ready. The control they pressed becomes the indicator of what’s happening, which keeps the dashboard quiet while a multi-step agent runs underneath.

I owned the full Heroku deployment cycle for the frontend. For an MVP that already carried real backend cost (vector store, LLM calls, Redis tier, dead-letter handling), keeping the deploy loop down to single-digit minutes meant we iterated on the surface that mattered for sign-ups instead of fighting platform overhead.

Outcome

The system was built end-to-end and reached a working MVP — agent flow, RAG retrieval with per-store namespaces, Redis queues with dead-letter handling, Gmail send path, and the operator-facing surface visible in the screenshot above. The landing copy (“1 Month FREE, no card required”) is what we built around as the launch story.

The product never went public. The product owner ultimately discontinued the initiative for product reasons — the technical work was done. The architecture and the integration boundary it forced — sync-feeling UI over a queue-driven multi-step agent — are what’s worth showing.

I owned the frontend stack end-to-end: Remix.js, Polaris + App Bridge, Clerk, Prisma, Heroku Docker deploy. The backend — FastAPI wrapping the LangGraph agent (categorize → RAG → draft → verify → send/rewrite loop), Pinecone with per-store namespaces, Redis queue + pub/sub + dead-letter with 3-retry, Gmail toolkit, OpenAI + Groq — was the team’s, and I integrated against it.