Vimu KaleLet’s talk

AI · Architecture · Optimisation

Hard problems, untangled.

I’m Vimu, a software engineer who designs AI systems and the architecture around them, then makes them fast. I do my best work when the answer isn’t obvious yet.

Follow the threadSay hello

I work across the whole problem: the model, the architecture, the data and the interface. Give me something tangled, and I’ll find the thread, design the simplest system that holds, and make it fast.

01 Method

How I untangle things.

  1. 01

    Find the shape

    Most problems are hard because nobody has framed them yet. I work out what would make the problem go away before deciding what to build.

  2. 02

    Design the simplest system

    Then the smallest architecture that solves it: clear boundaries, standard interfaces, nothing clever without a reason.

  3. 03

    Make it fast

    Finally I measure, and optimise where the numbers say it matters, not where it feels like it might.

02 Selected work

Seven problems, solved.

Across AI, data, platforms and fintech. Client names stay private; the problem, the architecture and the reasoning behind it don’t.

01AI · Real-time data

Early warnings from a live stream of vitals

Remote patient monitoring · Senior full stack engineer

The problem

Medical devices send readings around the clock, and a care team can only watch so many screens. What matters is the trend in someone’s numbers, not any single reading.

What I built

I built the real-time provider dashboard, the predictive analytics that flag patients whose health is slipping, and the automated alerts, connected to medical devices and EHR systems.

DevicesIngestPostgreSQLDashboardEHR · FHIRRisk modelAlerts

Decisions

  1. Live on screen, history in the database. Readings reach the dashboard as they arrive and are kept in PostgreSQL, so providers see the moment and the trend behind it.
  2. Predictions that raise a hand. A risk model watches each patient’s readings and turns a slipping trend into an alert for the care team.
  3. Standards at the edges. Devices and EHR systems connect through FHIR, so readings flow into the patient record.
  • React
  • Node.js
  • PostgreSQL
  • Machine learning
  • FHIR

02Machine learning · End to end

A prediction model that learns from every outcome

Maternal health · ML engineer and full stack developer

The problem

Expectant mothers and their doctors plan for birth with incomplete information. A model can help, but only if it stays accurate as new outcomes come in.

What I built

I trained a predictive model on historical birth data, served it behind an API, and built the web app patients and doctors use, plus the secure pipeline that feeds new outcomes back into training.

Past outcomesTensorFlowFastAPISecure pipelineReact app

Decisions

  1. The model as a service. The TensorFlow model is served through FastAPI, so the model and the interface ship on their own schedules.
  2. A loop that keeps learning. New outcomes flow back through a secure pipeline into training, so predictions improve over time.
  3. One app, two audiences. Patients and doctors use the same React app, each with views of their own.
  • Python
  • TensorFlow
  • FastAPI
  • React
  • PostgreSQL

03LLMs · Product

A language model where trust matters most

Mental health support · AI integration lead

The problem

People need support between therapy sessions. A conversational assistant can help, but only if its prompts, safety rules and data are handled with real care.

What I built

I led the AI integration for a conversational assistant that offers personal recommendations and tracks mood over time, alongside secure video sessions and a dashboard where therapists follow progress.

Patient appNestJS APILanguage modelWebRTCMongoDBTherapist

Decisions

  1. The model sits behind the API. Conversations reach the language model through the NestJS backend, so prompts and safety rules live in one place.
  2. Video straight between people. Sessions run on WebRTC, peer to peer between therapist and patient.
  3. Records that can grow. Check-ins and conversations are documents in MongoDB, free to gain new fields as the product learns.
  • React
  • OpenAI API
  • NestJS
  • MongoDB
  • WebRTC

04Architecture · Platform

A platform built to change one piece at a time

Healthcare operations · Full stack developer

The problem

Scheduling, documentation and care plans each have their own rules, and all of them touch the same records. Built as one block, every change would risk the rest.

What I built

I architected and built both sides: the modular API that moves the data, and the screens teams work in all day, from scheduling and documentation to care plans and real-time insights.

Patient appTeam appSMART on FHIRSchedulingDocumentationCare plansMedplum

Decisions

  1. One module per workflow. The NestJS API is split into modules for scheduling, documentation and care plans, each with its own boundaries, so one can change without breaking the others.
  2. A standard as the data model. Records live as FHIR resources on Medplum rather than in a schema of our own, so the data stays portable and every integration speaks the same language.
  3. Access through the standard. People sign in with SMART on FHIR and OAuth2, so permissions follow the standard instead of custom rules.
  • React
  • NestJS
  • TypeScript
  • Medplum
  • FHIR
  • SMART on FHIR
  • OAuth2

05Real-time · Frontend architecture

Many people, one live report

Business intelligence · Frontend architect

The problem

Teams wanted to build and edit reports together, live, instead of passing files around and waiting for refreshes.

What I built

I architected the frontend: a real-time collaborative interface for data visualisation, a drag-and-drop report builder, and sharing with fine-grained permissions.

EditorEditorWebSocketReduxD3 chartsBuilderSharing

Decisions

  1. One store, many editors. Report state lives in Redux Toolkit and syncs over WebSockets, so everyone sees the same report as it changes.
  2. D3 draws, React arranges. D3 renders the charts, while React owns the layout, the builder and the sharing screens.
  3. Permissions per report. Every report carries fine-grained sharing: who can view it, edit it or pass it on.
  • React
  • Redux Toolkit
  • D3.js
  • WebSocket
  • Material UI

06Systems integration

One clean layer between a platform and a hospital

Hospital records · Integration specialist

The problem

A patient assistance platform needed data from Epic, which speaks two standards and changes on its own schedule. Wired straight to it, the platform would inherit every quirk.

What I built

I built the integration layer between the platform and Epic: patient data sync, medication management and workflow automation, with HIPAA compliance from day one.

PlatformSMART on FHIRIntegration layerHIPAA controlsEpic FHIREpic HL7

Decisions

  1. One layer in between. A single integration layer owns every connection to the hospital record, so changes on either side stay contained.
  2. FHIR and HL7 side by side. The layer speaks both standards, and each workflow uses the interface it needs.
  3. Compliance from the first line. HIPAA compliance and data security were requirements from day one, not a later audit.
  • FHIR
  • HL7
  • Epic APIs
  • SMART on FHIR
  • Medplum
  • Node.js

07APIs · Distributed systems

Metering and limits that hold on every server

Fintech data APIs · Full stack developer

The problem

Selling data APIs by subscription means counting every call, enforcing each tier’s limits and billing for usage, consistently, however many servers are running.

What I built

I built usage-based billing on Stripe, distributed rate limiting, an analytics dashboard and automated customer onboarding.

CustomersNext.js APIRedisCredit dataStripePostgreSQL

Decisions

  1. Pay for what you use. Every call is metered and billed by tier through Stripe.
  2. Limits that hold everywhere. Request counts live in Redis, so rate limits apply across every server rather than per instance.
  3. The same containers everywhere. The whole stack runs in Docker, so development matches production.
  • Next.js
  • Stripe
  • PostgreSQL
  • Redis
  • Docker

03 Range

All-rounder, by design.

  1. AI and machine learning

    Models where they earn their place, and everything around them.

    • LLM integration
    • OpenAI API
    • On-device AI
    • MCP
    • TensorFlow
    • Python
    • FastAPI
    • Predictive models

  2. Architecture

    Systems that stay simple as they grow.

    • System design
    • Modular APIs
    • NestJS
    • Real-time: WebSocket and WebRTC
    • Integration layers
    • FHIR and HL7
    • Docker
    • AWS

  3. Performance and scale

    Measure first, then make it fast.

    • Redis
    • PostgreSQL
    • MongoDB
    • Rate limiting
    • Cloudflare Workers
    • WebGL

  4. Product engineering

    The interface is part of the solution.

    • React
    • TypeScript
    • Next.js
    • Node.js
    • Astro
    • D3.js
    • GSAP
    • Three.js

Shipped in healthcare, fintech and business intelligence. Around the code, I mentor developers, pair on the hard parts and review to share the why, not just the what.

04 Side quest

Qwantarc Farms

A plant nursery online, where every plant is drawn by code, leans toward your cursor and follows the sun as you scroll.

Visit the nursery

05 Contact

Got a tangle? Let’s pull the thread.

A project, a role, an architecture review or just a hello. Every message reaches me directly.

What is it about?

Enter your name.

Enter an email address I can reply to.

Write a short message.

It goes straight to my inbox.