Offline-first
Works where the network does not.
- Data saved on the phone, synced when a signal returns
- No lost work on a weak connection
AI Led Engineering. Software built around the work.
Our engineers work with AI from the first conversation to the last release, so a small team builds more, tests more and leaves you documented software you own.
It’s always domain first, technology second. We don’t write code until we understand the terrain: its realities, its regulations and its unsolved problems.
PM
Prashant Mehra
Cofounder & CEO, commons.inc
Cofounder & CEO, commons.inc
Not faster typing. A different way to build.
AI does not replace the engineer. It takes the slow, repetitive work off their hands, so their time goes into understanding the problem and getting the design right.
The usual buildAI Led Engineering
From idea to something realMonths of documents before anyone sees a screenA working prototype in days, tested with the people who will use it
TestsWritten last, and often skipped when time runs outWritten alongside the code, every time
DocumentationOut of date by the day it launchesGenerated from the code, so it stays current
The teamA large team, with slow hand-offs between rolesA small senior team that can safely take on more
After launchA support contract and a system only the vendor understandsSoftware your own team can read, change and run
From a first prototype to a platform for millions.
Every build starts from the people who will use it, and from the parts we have already built and proven in the field.
- 01Product and platform engineering
Full platforms built from scratch, for programmes that run across states, languages and partners.
- 02Field and mobile apps
Apps that work offline, in local languages, on the low-cost phones frontline workers already carry.
- 03AI inside your software
Assistants, voice in local languages, and reading forms and documents, built in where they save real time.
- 04Integrations
Connected to government systems, payment rails and the tools your teams already use, through governed APIs.
- 05Quality engineering
Automated testing on real devices and real networks, with AI writing and maintaining the tests.
- 06Run and improve
Monitoring, support and steady improvement after launch, by the team that built it.
Understand. Prototype. Build. Prove. Run.
Five stages, in short cycles. At every stage our engineers decide; AI does the heavy lifting around them.
- 01
Understand
Time with the people who will use it, before anything is designed.
Our engineers- Field visits and user interviews
- Decide what the first release must do
AI in the loop- Turns conversations into user stories
- Drafts the data model and the open questions
- 02
Prototype
Something real to react to, in days rather than months.
Our engineers- Choose what matters and what can wait
- Test the prototype with real users
AI in the loop- Generates screens and a working first version
- Rewrites quickly as feedback comes in
- 03
Build
Short releases, each one reviewed and shipped.
Our engineers- Design the architecture and own every change
- Review every line before it ships
AI in the loop- Drafts the code and its tests together
- Explains unfamiliar code to anyone on the team
- 04
Prove
Tested where it will be used, not only in the office.
Our engineers- Test on real devices and weak networks
- Sign off security and data protection
AI in the loop- Writes and maintains regression tests
- Flags security issues on every change
- 05
Run
We run it, or hand it to your team, with everything they need.
Our engineers- Monitoring, support and improvements
- Train your team to take it over
AI in the loop- Keeps the documentation current
- Helps sort and diagnose issues
Commons CodeMill. AI proposes, engineers decide.
CodeMill is how our engineers work. AI models sit in the codebase alongside the team: reading code, drafting changes, writing tests and reviewing every pull request.
The change is not in how fast people type. It is in what a small team can safely take on: work we once planned in quarters now moves in days.
Where AI helps on every build
- Reading code. Anyone on the team can ask how a part of the system works, and get an answer.
- Drafting changes. First versions of features, screens and fixes, ready for an engineer to shape.
- Writing tests. Every change arrives with the tests that prove it works.
- Reviewing. A second reader on every pull request, catching what tired eyes miss.
Built for the field. Not only for the office.
The four things every system we build does, whatever it is for.
Multilingual
In the language people speak.
- Hindi, Odia, Kannada and more
- Voice where reading is hard
Light on device
On the phones people already have.
- Fast on low-cost Android phones
- Small downloads, low data use
DPDP-ready
Personal data handled properly.
- Consent and notices built in
- Data kept in India
Three ways to work with us.
Pick the one that fits how much your own team wants to own.
- Fixed scope
A product, built
A defined product at a fixed price, delivered in releases you can use as they arrive.
Talk to us - Dedicated team
Our engineers, in your team
A small team of our engineers that plans and ships with yours, for as long as you need it.
Talk to us - Build, run, hand over
Yours, when you are ready
We build it and run it, then train your team and hand it over, documentation and all.
Talk to us
Speed without shortcuts.
AI makes it easy to produce code quickly. These rules make sure what we ship is code you can trust, on every engagement.
On every engagement
- Humans own every change — AI proposes; engineers decide. Nothing reaches production without review.
- Your code stays with you — we work in your repositories and environments, under your access controls.
- No training on your code — we use model agreements that do not learn from your work.
- Secure by default — security checks on every release, and personal data handled under the DPDP Act.
- You own it — the code, the documentation and the IP are yours.
Platforms we have built, running in the field.
Across every focus area we work in. Each started as a conversation with the people who would use it.
See the platforms we have built for healthcare.
See the platforms we have built for agriculture.
See the platforms we have built for education.
See the platforms we have built for skilling and employability.
See the platforms we have built for civic engagement.
See the platforms we have built for rural development.
See the platforms we have built for the back office.
Related insights & case studies.
Quick answers.
Only when it is treated like any other code: reviewed by engineers, covered by tests and released in small steps. That discipline, not the model, is what makes it safe.
You do. The code, the documentation and the intellectual property are yours, in your own repositories, from the first day.
That is the intent. Your engineers can work alongside ours from the start, and the documentation is kept current, so handing over is a step, not a project.
A working prototype usually comes within the first weeks, so decisions are made on something real rather than on documents.
Yes. We can connect to it, extend it, or replace it step by step. That last one is our Legacy Modernisation practice.
Start with a prototype, not a proposal.
Tell us about the work and the people doing it. We will come back with something you can try.