A government software engagement is not a commercial one with more paperwork. It is a different shape of project, and the constraint is rarely the technology.
Delhi's enterprise buyers are disproportionately institutional — ministries, regulators, PSU head offices, national institutions. What changes there is that the requirement arrives inside a procurement process with a fixed evaluation matrix, an audit trail that has to survive a CAG review, and a documentation burden most vendors discover after signing.
GFR 2017 shapes the engagement, not the code
The General Financial Rules govern how central government bodies spend. For a software build, three consequences matter:
- Evaluation is a matrix, not a conversation. Technical and financial scores are weighted in a published formula. A better architecture that scores the same as a worse one wins nothing, so the response has to be written to the matrix as well as to the problem.
- Payment follows documented milestones. Each release of funds needs evidence in a prescribed form. A build that ships working software without producing that evidence has completed the work and not the milestone.
- The audit comes later, and asks about process. Not whether the system works, but whether procurement and delivery followed the rules — and that evidence has to have been generated at the time.
GeM as a channel
The Government e-Marketplace is where much of this now runs. Two practical notes:
Eligibility floors are applied first. Turnover thresholds and past-performance requirements are arithmetic gates in the tender document, evaluated before technical merit. Checking them before writing a response saves both sides real time, and it is the most common reason a capable firm should not bid.
Pre-bid meetings matter more than they look. They are where ambiguity in a specification gets clarified on the record, and a clarification obtained there binds the evaluation. For central departments these are usually held in Delhi, and attending in person is worth the trip.
STQC is a schedule item
Standardisation Testing and Quality Certification audits a system against a defined checklist before it goes live on government infrastructure: application security, documentation, process evidence.
Teams treat it as a final gate and discover it is a design constraint. The artefacts it asks for — threat modelling, test evidence, documented change control — are cheap to produce during a build and expensive to reconstruct afterwards. A system that is functionally complete and has none of them is not close to ready.
Budget it as a phase with its own duration, and produce the evidence as you go.
Where it runs
Hosting is decided by data classification and by the tender, not by preference: on-premise, on NIC infrastructure, or with a MeitY-empanelled provider in a specified region. That choice constrains managed services, deployment tooling and sometimes the runtime, so it belongs in the first week of discovery.
What the software itself has to carry
Beyond the usual, three things recur in public-sector builds:
- Registers and approval chains as first-class concepts. Government processes run on recorded approvals in a defined order, often with a delegation hierarchy that changes by value band. A workflow engine that models this properly is the difference between adoption and a parallel paper file.
- An audit trail designed for reconstruction. Who did what, when, on whose authority, and what the record looked like before and after. The test is whether a decision from three years ago can be reproduced.
- Accessibility, tested. Public-sector procurement increasingly asks for WCAG conformance, and it is far cheaper as a foundation than as remediation on a live citizen-facing service.
India Stack, and one boundary worth stating
DigiLocker issuance and verification and API Setu data exchange are routine integrations, and usually reduce both effort and fraud.
Aadhaar is different. Authentication and eKYC run through a licensed AUA or KUA, so what is possible depends on the department's own authorisation rather than on the vendor's. We build to that boundary rather than around it — and where a department is not authorised, DigiLocker-based verification generally meets the same need.
Build-Operate-Transfer fits this sector unusually well
Public bodies frequently want the capability in-house eventually but lack the staffing to start there. A structure that delivers the platform, operates it under SLA, and transfers it with documentation and trained people matches how these organisations actually work — and it answers the question every evaluation committee asks about what happens when the contract ends.
The honest summary
The technology in a government build is rarely the hard part. The hard parts are an evaluation matrix that rewards a particular kind of response, evidence that must be generated during delivery rather than after it, and hosting decided before the architecture. All three are knowable at the start, and all three are expensive to discover at the end.