I build the layer between applications and language models: policy engines, agent runtimes, and the SDKs that carry them into production.

Teams shipping LLM features scatter guardrail logic across prompts, application code, and post-processing. The rules become impossible to audit, and changing one means a redeploy.

A real-time policy engine between the application and the model provider. Policies are declared and versioned separately from application code, then evaluated on every request. The model itself is never modified.

• Wrap the provider call, do not fine-tune the model

  Enforcement happens at the boundary, so a policy change takes effect on the next request instead of the next training run.

• Policies as data, not code

  Declarative rules can be versioned, diffed, and audited. That is the property teams actually need when someone asks what the system was permitted to do last March.

• One SDK, four providers

  OpenAI, Anthropic, LangChain, and LangGraph sit behind a single TypeScript interface, so the policy layer survives a provider swap.

An AI agent fails quietly. Users hit a wall mid-conversation and leave, and the team finds out from a churn number weeks later, not from the transcript where it happened.

A runtime that reads every session to find where users stall, then re-activates them with in-chat guidance delivered through a frontend-only React SDK. No backend changes, no redeploy.

• Frontend-only integration

  Guidance ships through the React SDK, so a team can add it without touching their backend or redeploying their agent.

• Self-owned analytics

  The server SDK forwards to the cloud or keeps data in-house, instrumented with OpenTelemetry so OpenAI and Anthropic calls trace like any other span.

Buyers are moving from search engines to AI assistants. Most catalogs are built for rendering, not retrieval, so models scrape a page and guess at pricing, availability, and attributes.

A monorepo that structures product data for LLM consumption and distributes it to AI clients, with analytics on how and where that data is actually retrieved.

• Model for retrieval, not for rendering

  The same catalog serves a browser and a language model, but only one of them can infer meaning from layout. The structured representation is the source of truth.

• Modular monorepo

  Analytics, billing, integrations, and webhook pipelines are separate modules behind one NestJS backend, so a new integration never touches billing.

Fares arrive from several airline providers plus in-house aircraft, each with its own shape, rules, and availability. A traveller needs one number: the lowest fare that is actually bookable right now.

A dynamic pricing engine computing fares across variable rules, routes, and booking conditions, behind a comparison layer that aggregates external providers alongside in-house inventory, normalises the results, and surfaces the lowest available fare in real time.

• Normalise at the boundary

  Each provider is adapted into one internal fare shape on arrival, so comparison logic never learns a provider's quirks.

• Model the domain properly

  20+ data models covering aircraft creation, scheduling, availability, and reservations. The domain is the product, and shortcuts there resurface as booking bugs.