Daniyal Asif · Full-stack / AI builder in Lahore

I build practical AI tools with Python backends, React interfaces, and clear user flows.

My projects usually start with a messy workflow: a model, some moving data, and a user who needs to understand what happened. I turn that into something usable, testable, and easier to trust.

Recently: AegisFlow for multi-agent decision simulations, OncoTriage AI for evidence-led variant review, RescueRoute for live disaster routing, and a small prompt optimizer that is actually deployed.
GitHub

My usual build pattern

Show what happened, then let the user decide.

PRACTICAL AI
01

Messy input

User goal, rough data, constraints

02

Backend path

APIs, state, retrieval, routing

03

Model step

Prompt rules and bounded inference

04

Check the result

Sources, mode, fallback state

05

User decision

Clear output and next step

What I avoid

I try not to make AI look more reliable than it is. If something is guessed, missing, or running in fallback mode, the interface should make that obvious.

Python APIs + React screens
I build both sides of the product, from FastAPI services to the interface people use.
AI with visible limits
My AI projects show sources, fallbacks, and review steps instead of hiding them.
Live systems, not static mockups
RescueRoute streams fleet updates, AegisFlow mutates state, and the prompt tool is deployed.
Practical over fancy
I care more about a working vertical slice than a perfect-looking demo that does nothing.

Selected work

Projects with real product constraints.

Each project here has a clear problem, a working implementation, and a reason behind the technical choices. I want the work to show how I build, not just what the final screen looks like.

Multi-agent decision simulator — June 2026

AegisFlow

AegisFlow simulates high-stakes decisions with multiple AI agents. Each agent proposes an action, a critic reviews it, and the dashboard shows what changed before anything is committed.

Problem

For operational work, one model answer is not enough. Users need to see who proposed what, why it was accepted or rejected, and how the system state changed.

What I built

I built the FastAPI backend, Next.js dashboard, agent roles, critic review loop, state engine, shared schemas, Gemini live/sandbox modes, and Docker setup.

What this proves

  • Designed a six-node workflow graph from context prep through proposal generation, critic review, consensus, state mutation, and commit logs.
  • Modeled clinical triage, disaster response, and supply-chain scenarios with specialist roles and domain metrics.
  • Added sandbox mode, human override controls, confidence scoring, and structured audit trails for safer simulation behavior.
PythonFastAPINext.jsReact 19Gemini SDKPydanticDocker
View codeCase study

Workflow graph

Specialist agents can propose actions, but deterministic rules and critic review decide what is committed to state.

Case Study
  1. 1Context prep
  2. 2Agent proposals
  3. 3Critic review
  4. 4Consensus
  5. 5State mutation
  6. 6Audit log

Genomic review copilot — March 2026

OncoTriage AI

A Streamlit tool for reviewing BRCA variants without mixing up retrieved evidence and model interpretation.

Problem

In medical-style workflows, the risk is not just a wrong answer. It is making an uncertain answer look more supported than it is.

What I built

I built the Python review flow, Streamlit UI, evidence lookup paths, LIVE/DEMO mode handling, and source-first output structure.

What this proves

  • Decoupled evidence retrieval from scoring so review outputs stay auditable.
  • Added visible provenance, mode state, and fallback behavior instead of hiding failures.
  • Designed the UI around safe review boundaries rather than blind model trust.
PythonStreamlitNVIDIA NIMClinVarBRCA ExchangeProvenance
View codeCase study

Review boundary

Evidence and scoring are separate paths so the user can see what was found, inferred, and unavailable.

Case Study
  1. 1Variant
  2. 2Evidence lookup
  3. 3Model scoring
  4. 4Provenance UI
  5. 5Fallback

Disaster routing simulator — February 2026

RescueRoute AI

A 48-hour disaster-response simulation with live fleet state, route planning, and an operator dashboard over a moving map.

Problem

Emergency-response tools are only useful if operators can see what is moving, why a route changed, and what needs attention next.

What I built

I built a FastAPI and Next.js system with one-second SSE updates, A* routing, incident state, and an operator dashboard over a 2,500-cell grid.

What this proves

  • Shipped a 2,100+ LOC real-time simulation under a 48-hour constraint.
  • Implemented one-second SSE refresh cycles for live fleet synchronization.
  • Engineered obstacle-aware A* pathfinding across a 2,500-cell grid.
PythonFastAPINext.jsGemini APIA* PathfindingSSE
LiveView code

Fleet loop

The UI refreshes from backend state instead of pretending the route plan is static.

Live
  1. 1Incident
  2. 2Dispatcher
  3. 3Route engine
  4. 4SSE stream
  5. 5Operator UI

Prompt refinement tool — August 2025

AI Prompt Optimizer

A small deployed utility that turns rough intent into clearer prompts developers can compare, reuse, and refine.

Problem

Prompt iteration gets messy quickly when there is no structure for comparing intent, output, and revisions.

What I built

I built the Next.js interface, Gemini-backed refinement flow, comparison path, and Vercel deployment.

What this proves

  • Designed a practical refinement flow for clearer LLM instructions.
  • Kept prompt logic separate from interface and deployment concerns.
  • Maintained the Vercel deployment as a usable tool rather than a local demo.
Next.jsTypeScriptGemini APITailwind CSSVercel
LiveView code

Prompt path

The tool keeps the workflow narrow: clarify the request, compare the output, and keep the UI direct.

Live
  1. 1Rough intent
  2. 2Structure
  3. 3Refinement
  4. 4Comparison
  5. 5Output

Approach

How I usually work.

I like projects where the first version is messy: unclear data, rough user decisions, and a model that needs guardrails. My job is to make the path clear enough to build, test, and improve.

01

Start with the user's decision

I first map what the user is trying to decide, what they need to see, and where the product can mislead them.

02

Keep the moving parts readable

APIs, state, model calls, and UI should be simple enough that I can debug them without guessing.

03

Be clear when the AI is unsure

If data is missing, a model falls back, or a result is inferred, the interface should say that plainly.

04

Build something people can try

Even a portfolio project should have a working path, visible behavior, and enough polish to feel real.

05

Ship the slice, then harden it

I prefer a working vertical slice first, then tighten validation, edge cases, tests, and deployment.

Capabilities

Where I am useful.

I am strongest when I can connect the backend, the model call, the interface, and the deployment instead of treating them as separate pieces.

Backend & APIs

Seen in AegisFlow

I build Python APIs, async flows, live updates, and service boundaries that are easy to trace when something breaks.

PythonFastAPIAsync APIsRESTSSEDockerRender

LLM Workflow Design

Seen in AegisFlow

I use models where they help, then design the surrounding product so sources, limits, and fallbacks are clear.

LLM IntegrationGemini SDKNVIDIA NIMCritic ReviewPrompt Logic

Frontend/Product UI

Seen in AI Prompt Optimizer

I build React and Next.js interfaces that make the backend state, model output, and user action easy to follow.

ReactNext.jsTypeScriptStreamlitTailwind CSSVercel

Reliability & Delivery

Seen in AegisFlow

I care about the unglamorous parts: validation, failure states, deployment, and code that can be maintained.

Failure HandlingAudit TrailsValidationDockerDeployment

About

I am a self-directed full-stack builder based in Lahore.

I work mostly with Python, FastAPI, React, Next.js, and LLM APIs. I like building the whole path: backend logic, product UI, deployment, and the small details that make a demo feel usable.

My recent projects lean toward applied AI because that is where the product problems are interesting: what should the model handle, what should stay deterministic, what should the user see, and what needs a fallback.

I am looking for remote full-stack or AI engineering work where I can build practical tools, not just wire a model into a pretty screen.

ContactGitHubLinkedIn

How I work

  • I like boring, debuggable code more than clever abstractions.
  • I would rather ship a working slice than talk around an idea.
  • I separate model output from deterministic product logic.
  • I design screens so the user can see what changed.
  • I improve demos after the core behavior is real.

Focused on now

AI workflow toolsPython and Next.js productsInterfaces that explain stateRemote full-stack / AI engineering opportunities

Quick facts

Lahore, Pakistan. Available for remote work.

Google IT Automation with Python, Google Advanced Data Analytics, Google AI Essentials, Google Prompting Essentials.

English, Urdu, and Hindi.

Contact

Have a product, workflow, or role where this kind of work fits?

Send the context, goal, and timeline. I am most useful when the work involves backend systems, AI workflows, product interfaces, or turning a rough idea into something people can actually use.

Typical reasons people get in touch

  • AI product prototypes
  • Full-stack web apps
  • LLM workflow design
  • Backend/API implementation
  • Remote engineering opportunities
GitHubLinkedIn

Direct contact

Contact details are reveal-based. The form below opens a mailto draft in your default email client; it does not send server-side mail.

Email

Available on reveal

Phone

Available on reveal