Case Studies

How the work actually got done.

Two products we designed and engineered ourselves, and two worked scenarios showing how an engagement runs. We'll be explicit about which is which.

A note on evidence

YGL is early. There are no client logos, testimonials, satisfaction scores or revenue figures on this site, because there is nothing truthful to put there yet — and a fabricated number is worth less than an honest gap.

What we do have is two products with real architecture you can read about in detail. The scenarios below are labelled illustrative engagement — they show method, not results, and no client is implied.

Products built by YGL

Systems we shipped ourselves.

Built by YGLFitRas · built by YGL

An AI vision pipeline that refuses to guess

Nutrition tracking fails because logging a meal costs more effort than the insight returns. FitRas replaces manual entry with a photo — and gates the answer when the model isn't sure.

The challenge

Food recognition is easy to demo and hard to trust. A model will confidently return macros for a portion it cannot actually see, and a confidently wrong calorie count is worse for the user than no answer at all. Regional cuisine makes it harder still, since the food databases most apps depend on barely cover it.

The approach

Split recognition and nutrition calculation into two distinct stages so each can be evaluated separately
Introduced a portion gate: when the quantity is ambiguous, the API returns a needs-clarification response instead of a number
Checked a local food database on the fast path before falling through to model calculation
Wired the pipeline into CI with fixed accuracy thresholds that fail the build when breached
Layered a pgvector memory system underneath the coaching agents so advice reflects the user's actual history

What exists now

A two-step vision pipeline running in production code across web, iOS and Android
Recognition quality enforced in CI: success rate at or above 90%, wrong-accept rate at or below 2%
Three specialised AI agents with separate prompts, memory namespaces and rate limits
Dashboard load consolidated from several API calls into one cached, deduplicated request
Not publicly launched — no adoption figures are claimed

Full product breakdown

Built by YGLInstaBrain · built by YGL

Making a graveyard of saved reels searchable

Short-form video holds real information in a format you cannot search. InstaBrain turns it into structured notes and makes the whole library answerable in plain language.

The challenge

Extracting knowledge from video means chaining several models — fetch, transcribe, analyse, embed — where any one can fail or return something unusable. The content is also frequently Hinglish, which most transcription and analysis stacks handle badly, and a large share of reels require an authenticated session to fetch at all.

The approach

Built the pipeline as discrete stages so each can be swapped, retried and priced independently
Streamed job progress to the client rather than polling, keeping a slow operation responsive
Treated code-switched Hinglish as a first-class case in both transcription and analysis prompts
Stored embeddings alongside structured records so semantic and keyword retrieval share one row
Added a silent full-text fallback so a vector-service outage degrades quality instead of erroring
Shipped a browser extension to supply session cookies for reels that need a login

What exists now

A working pipeline from video URL to categorised, tagged, searchable note
Natural-language retrieval across a personal library using vector similarity
Category-specific structured metadata rather than generic summaries
Capture through iOS share sheet, browser extension and web paste
Not publicly launched — no adoption figures are claimed

Full product breakdown

Illustrative scenarios

How an engagement runs.

These are worked examples, not clients. They exist to show the method and the sequence of decisions — no company, no outcome and no metric below is real.

Illustrative engagementAI Automation · Consulting

Cutting first-response time on support triage

A worked example of how an AI automation engagement runs, from discovery through to a deployed classifier with a human in the loop.

The situation

A mid-sized SaaS team handles inbound support across email and chat. Every ticket is read by a human before it can be routed, which means the queue moves at the speed of whoever is triaging that morning, and specialist issues sit for hours before reaching the person who can solve them.

How we'd approach it

Discovery: sample several months of historical tickets and measure how they were actually routed, not how the documented process says they should be
Establish a baseline — current routing accuracy and time-to-correct-owner — before building anything
Prototype a classifier against the historical set and compare it to the human baseline on the same data
Design the confidence threshold: auto-route above it, queue for human triage below it
Instrument every decision so misroutes are visible and the threshold can be tuned with evidence

What would be delivered

A routing service with an evaluation harness that runs on every deploy
A confidence threshold tuned against measured cost of a misroute rather than a round number
Human review preserved for low-confidence cases instead of removed
A dashboard showing routing accuracy over time
Illustrative scenario — no client, no measured results are being claimed

Illustrative engagementApp Rescue · Product Engineering

From AI-assisted prototype to a production application

A worked example of an App Rescue: what the assessment looks at, what usually turns out to be wrong, and the order the repairs happen in.

The situation

A founder has an application built quickly with AI coding tools. It demos well. It also has API keys in the client bundle, no database migrations, authentication that trusts a value from the browser, and no error tracking — so nobody knows what breaks in the hands of a real user.

How we'd approach it

Assessment first: read the code, run it, and separate what blocks launch from what is merely untidy
Fix the security issues before anything else — credentials, authorisation checks moved server-side, row-level access rules
Establish a real data layer: schema, migrations, constraints, backups
Add observability early, so the remaining work is guided by actual failures rather than guesses
Only then extend features or convert to mobile

What would be delivered

A written audit separating blocking issues from deferrable debt
Security findings resolved before any feature work begins
A repeatable deployment and migration process
Monitoring and error tracking in place ahead of launch
Illustrative scenario — no client, no measured results are being claimed

Client feedback

Nothing here yet — on purpose.

This section is built and ready. It stays empty until a real client says something worth putting here, in their own words. No stand-ins.

First engagements are underway. When one wraps and the client is willing to put their name on it, their words go here — not before.

Your turn

Want to be the next one?

Tell us what you're building — or what stopped building.

Start a Project Explore the products