At Project Tech4Dev, we build open-source technology for the social sector. Our products — Dalgo, Kaapi, and Glific — power data pipelines, AI safety layers, and communication tools for NGOs across India. In mid-2025, we made a deliberate decision: go all in on AI-assisted development. This is a narrative account of that journey, what we learned, and where we are going.
From co-pilot to context engineering
The team’s starting point was GitHub Co-Pilot — useful for refactoring a function, generating test cases, or unblocking a quick infra question on AWS or Kubernetes. But it was, as one engineer put it, “just ChatGPTing in your VSCode.” It did not fundamentally change how we built software.
The next step was agentic tools — Cursor and Co-Pilot agent mode. We used Cursor to build a full internal tool called the Dbt Project Manager, automating dbt SQL transformation workflows for our consulting team. It scaffolded the project well, but as the codebase grew, “it felt like fighting with Cursor rather than building.” Fixing one thing broke five others.
The breakthrough came when Claude Code released its Opus model. The insight that changed everything: context, context, context.
Siddhant who is an engineer on the Dalgo team has recently shared a blog on the details of how we use AI for engineering in detail here – https://projecttech4dev.org/building-software-in-the-ai-era-what-actually-works/
The Claude Code workflow we now run
1. Plan in English first. Write a complete feature spec covering high-level architecture, data flow, low-level design, schema, and API design. Code in English words before a line of code is written.
2. Generate an implementation plan with Claude. Feed the spec to Claude Code and ask it to produce a detailed implementation plan. This is where engineers nudge Claude’s direction before it touches the codebase.
3. Human approval of the plan. A person reviews the plan before Claude writes a single line. Nothing proceeds without sign-off.
4. Claude generates the implementation. Claude works across frontend and backend simultaneously — eliminating integration coordination overhead.
5. Human review and quality gate. All generated code is reviewed before it enters production. No AI output ships without human eyes on it.
This shift changed the work from writing specs + coding + debugging + reviewing, to specs + debugging + reviewing. We slightly change the above workflow to support other requirements such as generating documents, research etc. The results with these were measurable.
| PROJECT · DALGO Charts and dashboards for Dalgo v2 Dalgo is our open-source data pipeline and analytics platform for NGOs. After experimenting with chat-with-your-data and AI-summarized pipeline failures — features users did not adopt at the rate expected — we pivoted to what users actually needed: KPIs, metrics, reporting, and dashboards natively in the platform. Using Claude Code, the team designed, planned, and shipped the Charts and Dashboards feature for Dalgo v2. During Spike Week alone, the team built a full chart feature prototype that would have taken a minimum of four weeks by conventional development. We now maintain a public Git repo (DalgoT4D/dalgo-ai-gen) with context files, specs, and implementation plans so the entire workflow is reproducible and reviewable. |
| PROJECT · DALGO STRATEGY Dalgo Product Strategy documentation process Dalgo is a data analytics, pipeline and visualisation platform which is able to solve specific pain points for our customers. Ashwin who leads Dalgo suggested why not use a collaborative AI approach to draft our strategy for the upcoming year. We want to be able to cater to different types of customers and operate in multiple verticals. To this end, we want to evolve our product strategy to be fit for FY27 and beyond. We have been able to adapt Claude AI into our planning workflow so all the leads can lean in, own their areas and still collaborate and contribute to the end-end product strategy. We have ingested all the relevant files for Dalgo into an inputs folder and ask Claude to use these for context when we work on specific verticals like product trust, feature richness and product strategy. This gets its own git repo where we all collaborate and version control the documents as our strategy evolves. We are still experimenting and using md files with Obsidian, docx with drive and other flows. It is not perfect yet and we are still evolving it but it has certainly helped us think through different scenarios and perspectives while crafting our narrative for Dalgo. |
What we have learned
Context is the new oil — but not just any context. It must be structured: architecture docs, data flow diagrams, schema designs, and API contracts. A dump of a Word document is not enough. The more precisely you specify, the more precisely Claude delivers.
Engineers, product managers or designers are not going anywhere. The skills that become more valuable are planning, designing, understanding the why, architecture, debugging, and reviewing. What changes is the ratio of time spent writing code versus designing the systems for users. Claude handles the former; people own the latter.
| “It would have taken me 2 weeks just to understand the backend and frontend Dalgo repositories, but with Forgecode and Claude, within 20 minutes I was already developing.” — Pratiksha, Engineer, Dalgo team |
| “I had no idea we could do so much in so little time and with such ease. Planning is more fun now because you get to order around a bunch of developers (agents).” — Ishan Koradiya, Dalgo Engineering |
What next?
We now want to enable a collaborative way for the entire team to leverage AI on a daily basis.
To start with, we are setting up an experimental track in Dalgo with AI. Anybody in our team can think of a feature or enhancement and either vibe code or deliberately code with AI assistance and deploy it to a new environment called experiments.dalgo.org which will be available soon.
Imagine this – product manager coding the new Metrics feature or our marketing lead coding a new feature they heard being asked in the last bootcamp. This layer can be showcased to our customers to collect early feedback and refine further. The final decision and review lies with the respective functions like product manager understanding the need for a feature, designer seeing if the UX is easy to use and makes sense from the user perspective and, finally, engineering seeing if the feature is technically sound, can scale to our user base and is maintainable so we take it to production meeting all the necessary checks and balances.
We are also working to integrate AI into our process further so we can leverage the strength of people in our teams to contribute across verticals and do more across Marketing, BizDev, Product, Design, Engineering and Leadership teams.
To AI and beyond!
