Skip to case study
VK / 2026

01 SYSTEMS DOSSIER · REMOTEHIRE · 2024

Immibot.

An AI immigration assistant shaped as a workflow, not a one-shot chat box: ask only what the next decision needs, retrieve evidence, validate documents, and keep the user's context intact.

Archive / all work
RoleFull-Stack Engineer
CompanyRemoteHire
SurfaceAI · RAG · SaaS
PUBLIC INTERFACE CAPTURE / 01Immibot landing interface with country choices for Canada, the USA, and Australia, an immigration question field, and common question cards.
The public-safe visual proof shows the entry point: a country-aware prompt before the workflow branches into questions and evidence.
02THE PROBLEM

The hard part was keeping a complicated path legible.

Immigration questions are high-context. A useful answer depends on country, intent, profile details, documents, and changing source material. The product challenge was to make that complexity feel like a sequence of clear next steps.

I re-architected Immibot around a modular workflow: guest entry, adaptive questions, source-linked retrieval, document validation, eligibility scoring, recommendations, and history that could move into an account.

The system provides guidance and workflow software, not legal advice or a guarantee of eligibility.

03THE WALKTHROUGH

One conversation, several dependable hand-offs.

From first question to saved recommendation.

  1. 01

    Guest entry

    A visitor could start in one click. The guest session gave the workflow enough continuity to be useful before account creation.

    low-friction start
  2. 02

    Adaptive questions

    Questions followed the selected country and domain instead of forcing every person through the same static intake form.

    context-aware intake
  3. 03

    Retrieval + sources

    The agentic retrieval workflow paired an answer stream with official-source links so a response could be inspected, not just trusted on tone.

    evidence beside answer
  4. 04

    Validation + scoring

    Document checks and eligibility signals turned a conversation into a structured recommendation surface with visible limitations.

    structured decision support
  5. 05

    History + account continuity

    Persisted history moved from the guest session into the Clerk account so users did not have to restart the workflow after signup.

    continuity after signup
04THE ENGINEERING

Adapters kept the product extensible.

Country and domain logic could evolve without forking the whole experience.

Immibot workflow architectureA public-safe architecture map connecting the session layer, adaptive intake, retrieval and source links, document validation, eligibility scoring, and persisted history through a country and domain adapter boundary.PUBLIC-SAFE SYSTEM MAP · NO INTERNAL PROMPTS OR DATACOUNTRY / DOMAIN ADAPTER BOUNDARY01Session layerguest → accountClerk · history transfer02Intakeadaptive questionsprofile context03Retrieveweb / indexed sourcesofficial links04Validatedocument checksstructured signals05Scoreeligibility signalsrecommendationsADAPTER INTERFACECountry rules × domain questions × retrieval sourcesExtend the workflow without rewriting the conversation, persistence, or account layers.06Persisthistory + messages07Respondchat + sourcesANSWER STREAM · OFFICIAL-SOURCE LINKSImmibot mobile workflow architectureA vertical mobile map of guest entry, adaptive intake, source-linked retrieval, document and eligibility analysis, persisted history, and the adapter boundary.MOBILE WORKFLOW MAPGUEST → ACCOUNT · SHARED PRODUCT LAYERS01Session layerguest entry · history transfer02Adaptive intakecountry + domain questions03Retrieveanswer stream · official-source links04Analyzedocument checks · eligibility signals05Recommend + persistnext steps · history + messagesADAPTER INTERFACECountry rules × domain questions× retrieval sourcesExtend without rewritingconversation, persistence,or account layers.

Why this mattered. The conversation, persistence, account, and billing layers stayed shared while country rules, domain questions, and source adapters remained replaceable. That was the seam I protected as the system grew.

SearchAdviceDocument workflowEligibility

My ownership

I worked across Next.js, TypeScript, client state, API boundaries, Prisma/SQL persistence, Clerk auth, Stripe billing, PostHog analytics, and PWA deployment. The engineering tradeoff was to keep adapters and source links visible while the workflow grew.

Stack: Next.js / TypeScript · LangChain / Flowise · Prisma / SQL · Clerk / Stripe · PostHog · Vercel / PWA

05THE OUTCOME
GUEST → ACCOUNT

Guest entry and account continuity made the workflow usable before and after signup.

Product outcome · context carried forward

The product became a continuity system.

The recommendation was only one moment. The stronger product behavior was what happened around it: a guest could explore, return to persisted history, create an account, and carry forward context instead of restarting the workflow.

I also unified client state through Context API and useReducer, then added PostHog instrumentation for cohort and session analysis. The tradeoff was deliberate: invest in a stable workflow boundary before adding more intelligence to it.

Public-safe boundary. This page names shipped responsibilities, user-facing behavior, and listed technologies only; it does not publish applicant data, private prompts, proprietary rules, provider secrets, or customer information. Immibot is guidance/workflow software, not legal advice.