By Veekshitha, 2026 C4GT intern, Dalgo
When I first heard about C4GT through my instructors, I was interested in getting experience with a real open-source project. I went through the projects on the Badal platform and came across Dalgo, an open-source data platform that works with NGOs.
The selection process had two interview rounds, mostly around my proposal, projects I had worked on, why I wanted to apply, and how I could contribute. Eventually, I was selected as a C4GT Contributor and matched with Dalgo.
Starting with a codebase that wasn’t mine
My project was to build an Admin Portal for Dalgo.
The first challenge wasn’t writing the portal. It was understanding the codebase.
This was my first time working on a project of this size. Unlike my college projects, where I usually knew the entire structure because I had built it myself, Dalgo already had existing models, APIs, services, frontend components, authentication, permissions, tests, and years of decisions behind them.
I spent a lot of time setting up the project, understanding how the backend and frontend were connected, tracing APIs, and figuring out where my changes actually belonged.
One habit I developed was asking:
“Does this already exist somewhere?”
Before writing something new, I started looking for existing functions, patterns, and components that I could reuse. That became one of my biggest takeaways from working on an existing codebase.
What I built
The Admin Portal was meant to make several administrative tasks easier instead of requiring engineers to handle them manually.
Over roughly three months, I worked on:
- Organisation onboarding and management
- Cross-organisation user management
- Organisation-level feature flags
- A redesign of the feature-flag system into a multi-organisation toggle table
- Broadcast notifications
- Pagination and related backend/frontend work
What made the project meaningful to me was that it solved an actual problem rather than being just another project for a submission.
Some things I learned while building it
One of the most interesting decisions was around the Admin Portal login.
Initially, I planned to create a completely separate authentication system for admins, with its own session, cookie and shorter expiry. My thinking was that a high-privilege section should have its own authentication boundary.
During review, I was asked why we needed another login system when the application already had one.
I went back and investigated the existing authentication and authorization flow. I realised that I would still be relying on the same underlying permissions, while now having two authentication systems to maintain and test.
So instead of creating another system, I kept the separate admin sign-in experience but reused the existing authentication infrastructure underneath.
That was a good lesson for me: sometimes the better solution isn’t building something new, but understanding and reusing what already exists.
I had a similar experience with permissions. I was initially using a user flag to control Admin Portal access. During review, I was pointed towards the existing Super Admin role. After checking how it was already being used, I moved the admin routes to the existing permission mechanism instead of introducing another one.
Towards the end, I also found a bug in the broadcast notification flow. It was possible for an API request to create a notification with all delivery channels disabled. The request would succeed, but the notification would effectively go nowhere.
Finding that bug made me think more about what happens outside the normal UI flow and why API-level validation matters.
Learning from my mentor
Siddhant was my mentor throughout the project. He was always available when I had doubts, and we regularly connected to discuss issues and possible solutions.
What I appreciated most was that he didn’t always give me the answer directly.
Often, he would ask a question that made me go back and investigate the code myself.
For example, instead of simply telling me to reuse something, he would ask why I was creating another implementation when something similar already existed.
Those discussions changed how I look at code reviews. I started seeing feedback less as a correction and more as a reason to understand the system better.
About AI-assisted development
Another interesting part of the internship was seeing how Dalgo uses AI in its development workflow.
Before this, my idea of AI-assisted coding was mostly asking an AI tool for code, trying it, fixing errors, and continuing.
Dalgo’s approach is more structured. The team has a repository called dalgo-core containing commands, agents, skills and other context for working with the codebase.
I used the same workflow during my project.
For example, /product/write-spec helped turn an idea into a scoped specification. /engineering/plan-feature researched the existing codebase and created an implementation plan, including the potential blast radius of the change. /engineering/execute-plan then helped implement the feature milestone by milestone.
The important part was that AI wasn’t simply being used as:
“Write this feature for me.”
It was more like:
“Understand the problem, investigate the existing system, make a plan, implement it, and then review the result.”
From writing code to reviewing code
This was probably the biggest change in how I think about development.
Earlier, my process was mostly:
Think → Write code → Run → Fix → Repeat
With AI-assisted development, it became more like:
Understand → Plan → Implement → Review → Test → Verify
AI can handle a lot of the repetitive work, but I still had to decide whether the result actually made sense.
Is there already something I can reuse? Does this follow the existing pattern? What could this change break? Are the tests actually checking the important cases?
The AI can produce an answer quickly. The developer still has to decide whether that answer is correct.
Looking back
Overall, C4GT was a very valuable experience for me.
I came in having mostly worked on projects where I knew the entire codebase. I left having worked on a large open-source project, contributed to real features, gone through code reviews, written tests, debugged issues, and understood much better how a real engineering team works.
More importantly, I got to see how the concepts I learned in the classroom actually come together in a real product.
My biggest takeaway wasn’t a particular technology or feature. It was learning to slow down before writing code, look for what already exists, and question my first solution.
Working on Dalgo taught me that writing code is only one part of engineering. Understanding the system and making the right changes is just as important.
