How I Became an AI Engineer

Navya Sajjan

I didn’t become an AI engineer by training models in a notebook and calling it a portfolio. I became one because I kept getting handed (or chasing) real problems that needed something shipped—a clinic that needed to stop running on paper, parents who couldn’t find a therapy center for their kid, and students who needed feedback on practice tests faster than a teacher could give it. The models were never the hard part. Getting them into something that survives contact with real users, real data, and real uptime expectations — that’s where I actually learned the job.

So this isn’t a list of technologies. It’s the projects, in roughly the order they happened, and what each one actually forced me to learn.

Where it started: dashboards, not deep learning

Before any of this, I was building dashboards in Power BI and writing SQL. It sounds unglamorous next to “AI engineer,” but it’s where I learned the lesson that everything else builds on: a model that no one can read the output of is worthless. I spent a long time learning to make numbers legible to people who didn’t write the query, before I ever trained anything.

From there it went LSTM-based sentiment analysis, then an emotion-recognition system trained on the RAVDESS audio dataset. Neither of these shipped to real users. They were where I learned the unglamorous 80% of machine learning — cleaning data, fighting overfitting, realizing that a clean validation split mattered more than whatever architecture I’d picked that week.

Then I built something that actually had to work in real time, with a real person depending on it.

Vision-Powered Cursor — the first thing that had to actually work

This was a hands-free accessibility tool: facial-landmark tracking via MediaPipe and OpenCV, controlling a cursor in real time through PyAutoGUI. No undo button if it lagged. No “close enough” if it misread a gesture.

It hit 89% accuracy, won first place at Akar 2024, and ended up published in IEEE Xplore. It’s still the project I point to when someone asks if I can take research-grade work and actually finish it — not just get a result, but defend it in front of a review board.

What it taught me, mechanically: real-time computer vision lives or dies on latency, and “works in a demo” and “works when someone is relying on it” are two different bars.

90 Heal — my first time inside someone else’s compliance boundary

As a Data Analyst Intern at 90 Heal (Oct 2024 — May 2025), I built ETL pipelines that pulled together clinical, operational, and billing data, trained and evaluated models on Vertex AI, and built the dashboards that healthcare stakeholders actually used to make decisions.

This was the first time a mistake in my dashboard wasn’t a bad grade — it was a wrong number a clinic director might act on. That changes how carefully you check your joins.

Yuktii (DentalOS) — the project that turned me into a product engineer

This is the deepest thing I’ve built, and it’s the one I’d put in front of anyone who doubts I can own a system end to end. It’s live, running in two dental clinics, on real patient data, right now.

It’s a multi-tenant dental practice operating system — React, TypeScript, and Vite on the frontend, Node.js and Express on the backend, PostgreSQL through Prisma, JWT-based auth with refresh tokens, Cloudinary for storage. Architecturally it’s a central database plus a per-clinic database model, with three separate surfaces: the clinic app itself, an admin portal for platform operators, and a public site for acquisition and SEO.

The part I’m proudest of is the treatment template engine. An admin can publish a versioned, immutable template — root canal, crown, implant, whatever — and the moment a doctor applies it to a patient, the system auto-generates the treatment stages, the recall schedule, the lab requirements, and the communication plan, all linked together. Nobody has to remember to schedule the follow-up. The system already did it when the treatment was created.

Beyond that, it covers:

• The full patient record — medical history, consent (tracked separately for data processing, notifications, and AI use, each with its own timestamp and version), FDI dental charting with full history
• Chair-aware appointment scheduling with a real check-in/check-out/no-show lifecycle
• Prescriptions tied into inventory, billing with GST and multi-method payments, and a low-stock-aware inventory system
• A WhatsApp-integrated recall engine — Meta webhook verified, with delivery and read receipts and retry logic — which is honestly the part that keeps the clinic’s revenue from leaking out the back door through forgotten follow-ups
• Lab case tracking through an eleven-stage production lifecycle
• Role-based access that actually separates clinical data from front-desk access, full audit logging, and a real legal document suite (privacy policy, DPA, security docs)

Building this taught me how to design a permission model that holds up under a healthcare audit, not just a code review. It also taught me that versioning matters in places you wouldn’t expect — if you republish a treatment template, you can’t let it silently change the workflow for a patient who’s already mid-treatment under the old version.

ManoSetu — building trust as the actual product

ManoSetu connects parents, therapists, and Child Development Centers (CDCs) — it’s a marketplace and an operating system at the same time. TypeScript and Node.js on the backend, MongoDB, React on the front, Cashfree handling payments.

It’s live, with over 300 CDC listings on the platform. It handles AI-assisted developmental assessments, therapy recommendations, booking, payments, session notes, and follow-up tracking across the whole care journey.

The hard part of this one wasn’t the code. It was figuring out how a parent — often anxious, often a first-time user of anything like this — decides to trust a center they’ve never met. The product had to be the trust mechanism, not just the booking flow on top of it.

Ekluvya— my current role as an AI Engineer

I work at Eklavya as an AI Engineer — that’s the role, full stop, not a company I run. What I’m responsible for is the adaptive AI assessment platform for JEE/NEET aspirants.

It uses Groq’s Llama-3.3–70B for real-time question generation and diagnostic reporting, with a dynamic proficiency-scoring engine that adjusts difficulty per student as they go. Reports stream back over SSE, so a student watches the analysis build instead of staring at a loading spinner for fifteen seconds.

It’s generated over 500 real assessments and diagnostic reports for actual students. Building this taught me that prompt engineering isn’t really a writing skill — it’s an interface design problem. Streaming, latency, and what happens when the model gets something wrong mid-report matter just as much as the prompt itself.

Cortex OS—the founder operating system

Cortex OS is the most ambitious thing I’ve built, and it’s the one that pushed me past “I can integrate AI into a product” into “I can design the operating system a founder actually thinks in.” It’s a multi-company platform for startup founders that centralizes everything that normally lives in scattered spreadsheets, Notion docs, and someone’s memory.

Stack-wise: React 19, TypeScript, and Vite on the frontend, Node.js and Express on the backend; MongoDB through Mongoose, JWT auth with bcrypt password hashing, Cloudinary for document storage, and Google’s Gemini APIs doing the AI work.

The core idea is that a founder doesn’t just need a task list — they need a structured record of the company itself. So Cortex OS tracks:

• Legal entity and compliance — CIN, PAN, TAN, GSTIN, incorporation details, founder cap tables with ownership percentages that can’t exceed 100%, advisor records, and a compliance checklist with deadlines
• Operational records — every vendor, tool, subscription, and service the company pays for, with cost, billing cycle, renewal dates, owner, and the option to attach the actual contract PDF
• The Decision Vault — a place to actually write down why a call was made: the trade-offs considered, the mental models used, and an outcome field that gets revisited later (Success, Failure, Reversed) so founders can audit their own judgment over time
• Risk and assumption intelligence — every risk gets scored as probability × impact (out of 25), with anything above 12 flagged critical, and every assumption the company is operating on gets tracked with a confidence score and a validation status, so “we think our CAC will stay low” doesn’t just live in someone’s head untested
• People, roles, and finance — headcount with access levels and employment type, recurring vs. one-time expenses by category, and a burn/runway forecast with Realistic, Aggressive Growth, and Survival Mode scenarios at different burn multipliers
• AI-assisted capture — this is the part I’m most proud of. A founder can type an unstructured brain dump and Gemini classifies it into decisions, risks, tasks, people, or expenses automatically. There’s also live voice capture: it streams 16kHz audio straight to Gemini Live, transcribes in real time, and auto-structures the transcript into the same entity types every few seconds, so a founder can just talk through a planning session and walk away with structured records instead of a wall of notes

Building this taught me a different kind of system design than Yuktii did. A clinic has a known, fairly fixed shape — patients, appointments, treatments. A founder’s operating reality doesn’t. Cortex OS had to model ambiguity itself: an assumption that might be wrong, a risk that might never materialize, a decision that might get reversed in six months. Designing data models for things that are supposed to change their own confidence over time is a genuinely different problem than designing a CRUD app, and it’s the part of this build I think about the most.

Open5GS NMS — the project nobody expects an AI engineer to have built

This one is a genuine outlier on my resume, and I like it that way. It’s a Network Management System for Open5GS-based 5G core deployments — React, TypeScript, Node.js, and PostgreSQL on top, Prometheus and Grafana underneath for monitoring, all containerized with Docker.

It gives subscriber, traffic, and service-health analytics, and the integration layer was built to be reusable across different 5G core implementations rather than hardwired to one.

What I took from this is mostly about observability. Telecom infrastructure does not tolerate vague monitoring — you either know exactly what’s failing and where, or you don’t know anything. That discipline is the reason I think about uptime and alerting the way I do now in every SaaS product I build, including the 99.9% uptime target on Yuktii.

Market Pulse India — explaining markets instead of just listing events

Most economic calendars tell you that an RBI decision is happening. Market Pulse India was built to explain what it actually does to Nifty, Bank Nifty, gold, crude, and the rupee — before it happens, not after.

It’s built on Next.js, TypeScript, Tailwind, and ShadCN on the frontend, NestJS on the backend, PostgreSQL, Redis, and a notification layer running through Firebase, Twilio, and a Telegram bot. It has a tiered alert system — 7 days, 3 days, 1 day, 1 hour, and 15 minutes out — across Push, Email, Telegram, WhatsApp, and Slack, an AI intelligence engine generating pre- and post-market reports and volatility forecasts, and a liquidity-sweep engine that tries to predict where volatility is likely to cluster around a high-impact event.

Designing the alert architecture on Redis taught me a lot about multi-channel delivery at scale. Designing the AI-generated forecasts taught me something more uncomfortable: when you’re writing copy that influences someone’s trading decisions, you frame everything as probability, never certainty, even when the model sounds confident.

StudyBuddy AI, Shellwise, and the Reuse hackathon

Three smaller projects, each one a stepping stone rather than a destination.

StudyBuddy AI (FastAPI, Gemini, MongoDB) was my first real generative-AI application — early prompt engineering and API integration work that later became the technical foundation for the Eklavya assessment engine.

Shellwise was a business-operations project around eggshell processing and calcium carbonate production—not software-heavy, but it’s where I had to think hard about unit economics and operational constraints, which now shapes how I evaluate every product idea I take seriously.

The Reuse hackathon project was pure rapid prototyping under a hard deadline—a useful reminder that fast, constrained iteration is a skill on its own, separate from how deep your stack knowledge goes.

What actually adds up here

Nine projects that are products, not exercises three of them live with real users right now (Yuktii in two clinics, ManoSetu with 300+ CDC listings, and the Eklavya assessment platform with 500+ assessments generated). Five more that taught me the fundamentals before any of that was possible. Healthcare, EdTech, telecom infrastructure, fintech, and founder tooling, with one IEEE publication along the way.

If you ask me what I am, the honest answer depends on the room. To a recruiter, I’m an AI Product Engineer. To another engineer, I’m probably closer to someone who’s comfortable from the data layer all the way up to the UI, with the LLM and RAG side bolted on more recently than the rest. Either way, the thing I actually care about is the same: I don’t think a model is finished until it’s running somewhere, being used by someone, and still working a month later when nobody’s watching it.