DEV Community: Aarti Panchal

Shipping real products as a first engineering hire

Aarti Panchal — Mon, 10 Aug 2026 16:02:08 +0000

I joined an early stage startup as the first person on the team besides the two founders. The mandate was direct: build real products, with real data, fast. A few weeks later, the systems I worked on are live. This is the engineering write up, including the failures that taught me the most.

The through line is one idea: trustworthy data about workers. Understanding why they leave, and recording that they showed up.

Turning a static dashboard into a live trust score

The first product is a dashboard that runs and analyses worker exit interviews, powered by an AI voice agent.

When I started, most of the dashboard was a facade. Eleven of the twelve cards were hardcoded. So the real work was making them true. I built the Trust Score on an actual formula: four sub scores for Employer, Contractor, Location, and Regulatory signals, each computed from Firestore data. I added sanity guards so test and junk records could not skew the result.

The Trust Score, now computed from real Firestore data across Employer, Contractor, Location, and Regulatory signals.

A score is only useful if people trust it, so I made it explainable. Cards that break down how the score was reached, an insight panel that surfaces the single biggest challenge based on the lowest sub score, and a next job signal on the worker view. I also added a filter to the interview workflow and fixed a rendering mismatch where twelve cards were defined but only ten showed.

Making an AI voice interview feel instant

The interview itself runs over a phone call. Instead of HR calling every departing worker, a voice agent calls them in their own language and holds a natural conversation.

I led the technical integration with the voice platform on my own. To pin down the exact request format, I ran a spike that pointed the platform at httpbin so I could read the raw payload it was sending. That is how I found the cause of a failing POST and got it fixed on the vendor side.

The interview needs to react to what the worker says, so I built a separate endpoint server that sits between the platform and the model.

Latency was the hardest part. What moved the needle:

Have the model emit the spoken text first and the bookkeeping JSON last, so speech starts before the housekeeping is done.
Move the server to a Mumbai region and pre warm it before every call.
Keep every response under twenty words.

I also spent real time on conversation quality. I fixed how PF and ESIC are pronounced, spelling them letter by letter in all four languages, removed gossip style probing, and replaced abrupt hang ups with warm, language specific closings. One debugging lesson worth keeping: a 401 that looked like an auth bug was actually environment variables not taking effect until a fresh deploy.

A kiosk that records attendance by face

The second product is Inverix Attend. A tablet at the gate, and daily check in by face. It is multilingual, works offline, and is privacy first.

A few parts were interesting to build.

On device face recognition. Each face becomes a 128 number descriptor. Enrollment stores it, check in compares the live numbers against it, and nothing leaves the device except the match.

Privacy first by design. At enrollment we only ever keep a name, a photo, and a masked reference. No sensitive identity number is stored.

A Firestore constraint I learned the hard way. Firestore rejects nested arrays. My face templates were a list of number arrays, so the write threw a 400 that reached the browser as an empty 500. I now serialize the templates to a string and rebuild them on read.

Offline that actually works. Templates are cached, punches queue locally, and everything syncs when the connection returns.

The part I am most happy with: getting reliable recognition working entirely in the browser, so a worker's face never leaves the device, and the whole thing still holds up when the network drops.

Engineering takeaways

I moved fast by pairing with AI tools, and I want to be honest about that rather than hide it. But the judgment was mine. Reading the real 400 instead of trusting the vague 500. Deciding how the Trust Score should be computed. Running the vendor call. Choosing what to cut. That is where the actual engineering was, and it is the part that stuck.

The systems are live. On to the next one.

What C4GT Actually Is, and How to Get Into DMP 2027

Aarti Panchal — Sat, 01 Aug 2026 19:34:41 +0000

What C4GT Actually Is, and How to Get Into DMP 2027

I'm a second year B.Tech student. Right now I'm rebuilding the frontend of India's national 104 health helpline as a C4GT DMP Fellow. Six months ago I didn't know this program existed.

This is the guide I wanted then. No fluff, no motivational framing. Just what it is and how to get in.

1. What is C4GT

Code for GovTech connects developers to open source software that governments and public institutions actually run. Not simulations of civic tech. Live systems: health, education, welfare delivery, identity. These serve millions of people and are maintained in public repositories.

Why this matters more than it sounds: most government software in India is now built as Digital Public Goods, meaning open source, openly licensed, and reusable across states. That means the code is on GitHub and you can contribute to it. A platform serving a hundred million citizens will take your pull request if it's good.

The gap C4GT fills is that these repos are hard to enter cold. Large, sparsely documented, deep domain context. C4GT provides the structure: a fellowship, a mentor from the organization that owns the codebase, and a scoped project you can actually finish.

2. What is DMP

DMP is the fellowship track. It's a paid, mentored, fixed term program where you work on one Digital Public Good project with a real mentor from the maintaining organization. Details: pl-app.iiit.ac.in/c4gt.

How it runs, in shape:

Organizations publish project ideas with scope and required skills
You pick a project and apply through a form on the C4GT site
The form runs in stages, asking for your repositories, your education, your background, and why this project
Resume and proposal uploads are offered but optional
Selected fellows are paired with a mentor from that organization
Midterm evaluation at the halfway point: you present shipped work
Final evaluation at the end
Stipend paid across milestones

Two things that surprise people. First, it's not an internship where you're handed tickets. You shape the plan with your mentor and own delivery. Second, the code goes into the real repository. My PRs are merged into a system that live call operators use today.

3. What kind of projects

A real example: mine.

India's 104 health helpline is what a citizen dials for free health advice, medical guidance, and grievance reporting. Behind that number sits AMRIT, maintained by Piramal Swasthya. A health advisory officer answers, and inside one application does caller identification, beneficiary lookup, symptom capture, clinical decision support, and case closure.

That application was built on Angular 4, a framework long past end of life. npm audit on it reports 183 vulnerabilities. My project: rebuild the frontend on Angular 20 with standalone components, zoneless change detection, signals, ZardUI, Tailwind v4, SNOMED CT clinical coding, and CDSS integration.

At midterm: 30 PRs merged, 131 commits, 52 of 60 end to end scenarios passing.

Other projects run across health, education, welfare, agriculture, and identity, spanning backend, frontend, data, mobile, and DevOps. Browse the current list on the C4GT community platform; scope and stack vary widely.

4. How to apply

Read the project list at pl-app.iiit.ac.in/c4gt. Filter to projects whose stack you can already work in. You'll be learning the domain, so don't also be learning the language.
Join the C4GT Discord. This is the actual center of gravity. Announcements, mentor Q&A, other applicants. Join before applications open, not after.
Find the repo and read it. Every project maps to a public GitHub repo. Clone it. Build it. Get it running locally. This alone puts you ahead of most applicants.
Open a small PR before you apply. Fix a typo, tighten error handling, improve a README. A mentor who has already merged something of yours is evaluating a known quantity.
Ask your questions in public. Discord or a GitHub issue, not DMs. Mentors notice who engages carefully.
Fill in the application form on the C4GT site. You choose your project first, then work through several stages of questions covering your repositories, your education, and your background. Resume and proposal uploads are optional. Watch the deadline. There's no extension.

5. What to prepare

GitHub. Pinned repos with real READMEs: what it does, how to run it, a screenshot. Ten abandoned tutorial clones read worse than two finished projects. Commit history matters more than star count.

Resume, optional. One page. Lead with projects and what they do, not coursework. Link every repo. Skip the skills percentage bars.

The form answers. This is where it's actually decided. There is no formal proposal to write. You pick a project, then work through stages of questions inside the form, and those answers are what get read. What to have ready before you start:

Your repository links, strongest one first
Why this project, in terms of the problem it solves rather than how excited you are
What you would build, concretely: components, endpoints, screens
Evidence you read the code, referencing actual files and actual functions
Your education and background, which the form asks for directly

That fourth point is the differentiator. Most applicants describe the project back to the organization in more words. If your answer says "I looked at the auth service in src/app/core and here's how I'd migrate it," you're in a different pile.

The resume and proposal uploads are there if you want them. Use them only if you have something the form fields can't hold, like a migration plan or a longer technical note. Skip them if all they would do is repeat your answers.

6. What it's actually like

Honest version, three months in.

The codebase is nothing like coursework. Sixteen years of accumulated decisions, most undocumented. Functions that look wrong and aren't. They're compensating for backend quirks nobody wrote down. I learned this by deleting a few and breaking things. Reading legacy code well is a skill nobody teaches and everybody needs.

Senior devs will be direct with you. My mentor rejects PRs that aren't right. That felt sharp for about a week and then became the most useful thing in the fellowship. Nobody is protecting your feelings, and that's the respect.

AI assisted development helps in a specific, limited way. I used Claude Code for implementation and CodeRabbit for PR review. It genuinely collapsed the time to understand an unfamiliar codebase, and CodeRabbit caught real null safety and error handling bugs before review. But my hardest problem was not solvable by asking: integrating the CZentrix telephony system, which turned out to be an iframe communicating over postMessage and documented nowhere. That took instrumenting the old app and reading actual traffic. AI is fast at what code does and unreliable at why. Verify everything against the running system.

Write things down daily. I keep notes on every confirmed API contract, every environment quirk, every bug and cause. By month two I was answering my own questions from my own notes constantly. Nothing else I did had that return.

The moment that made it real: a live inbound call arrived on the test system. Caller's number populated. Timer started. Workspace loaded. A real phone call from somewhere in India, rendering into a UI I'd written. That's the difference between a project and infrastructure.

7. Links

C4GT: https://codeforgoodtech.in/
C4GT on GitHub: https://github.com/Code4GovTech/C4GT
Apply / community platform: https://pl-app.iiit.ac.in/c4gt
Discord: https://discord.gg/codeforgovtech
AMRIT / PSMRI repos: https://github.com/PSMRI
My GitHub: https://github.com/Aarti-panchal01
My portfolio: https://aarti-tech-portfolio.vercel.app
LinkedIn: https://linkedin.com/in/aartipanchal01

8. Start now

Applications for DMP 2027 aren't open yet, which is exactly why this is the right time.

Do this today: join the Discord. Pick one project from last cycle's list. Clone the repo and get it running. When applications open you'll have months of context while everyone else is reading the project description for the first time.

I applied assuming I wasn't ready. Second year, no industry experience, no idea if my answers were any good. They were good because I'd read the code.

That's the whole trick. Go read the code.

*Aarti Panchal. C4GT 2026 DMP Fellow at Piramal Swasthya, B.Tech AIML '28, PES University Bengaluru.
Questions welcome on My LinkedIn

A Live Call Landed: Rebuilding India's 104 Health Helpline from Angular 4 to Angular 20

Aarti Panchal — Sat, 01 Aug 2026 18:40:13 +0000

What I built

Helpline104-UI-NEXT is the new frontend for India's 104 health helpline, part of the AMRIT platform maintained by Piramal Swasthya Management and Research Institute (PSMRI). When a citizen dials 104, a health advisory officer picks up, and everything that happens next! caller identification, beneficiary lookup, symptom capture, clinical decision support, grievance filing, case closur. happens inside this application.

The version in production was built on Angular 4. That framework reached end of life years ago. npm audit on the legacy app reports 183 vulnerabilities. That's not a code-quality nitpick on a side project — it's the software layer sitting between a citizen's health question and the record of what they were told.

The rebuild targets Angular 20 with the current architecture end to end:

Standalone components — no NgModules anywhere in the new tree
Zoneless change detection — Zone.js removed entirely
Signals for state, replacing the legacy service-plus-subject patterns
ZardUI + Tailwind v4 for the component and design layer
SNOMED CT integration for clinically coded symptom and diagnosis capture
CDSS hooks so agents get decision support inline
CTI integration — the softphone lives in an iframe and communicates over postMessage

The rebuilt RO Dashboard — live agent ID, real UAT data

The numbers

Metric	Value
Pull requests merged	30
Commits	131
E2E scenarios passing	52 / 60
App-level bugs in latest full run	0
Vulnerable runtime dependencies in the rebuild	0 (npm audit --omit=dev)
Angular versions jumped	4 → 20

Dev tooling has 20 vulnerabilities (vite, ws, socket.io-adapter) — none shipped to production.

The hardest problem I solved

Getting a real inbound call to land in the new app.

The telephony side is a CZentrix CTI system. The softphone is an embedded iframe that pushes call events over postMessage. Nothing about that was written down. Figuring it out meant instrumenting the legacy app, watching what actually crossed the boundary, and reconstructing the contract from observed traffic.

Then came the ordering problems. A postMessage can arrive before authentication resolves, so the handler had to be gated on CTI-eligible auth state or it would process a call for a user who wasn't logged in yet. Agent ID parsing had an off-by-one in how the payload was split. Call state didn't survive a page reload so an agent refreshing mid-call lost the panel.

Then it worked.

A real inbound call came through on UAT. The caller's number auto-populated in the header. The call timer started counting. The agent workspace loaded with the right context. I watched a live phone call from somewhere in India render itself into a UI I had written, and there is no unit test that feels like that.

Live call, SNOMED CT returning real clinical concepts from UAT

What I learned with AI-assisted coding

I used Claude Code for implementation and CodeRabbit for automated PR review across the whole fellowship.

What it genuinely changed: reading a large unfamiliar codebase went from the slowest part of the job to a tractable one. CodeRabbit caught real defects — null-safety gaps, error banners that dismissed themselves too early, response shapes I'd assumed instead of verified.

What it did not change: the CTI integration was not solvable by asking. No model knew what CZentrix actually sent over postMessage because it wasn't documented anywhere. That required instrumenting the old app and reading actual traffic.

The pattern that held: AI is fast at what the code does and unreliable at why it does it. Every time I deleted something that looked wrong, it was compensating for a backend quirk nobody wrote down. Verify everything against the running system.

What's next

Close remaining E2E gaps — mostly waiting on backend fixes and reference data
Finish remaining supervisor configuration screens
Accessibility pass — keyboard navigation and screen reader support
Unit test coverage — zero specs today on signal stores and guards
Production deployment and handover documentation

30 PRs merged, every one reviewed by CodeRabbit + Mentor

Links

Thinking about applying to C4GT DMP 2027? The C4GT Discord is where it starts, and the C4GT community platform lists the projects. I applied assuming I wasn't ready. Second year, no industry experience, no idea if my proposal was any good. What's stopping you? Ask me anything in the comments.