The short answer
Under Law 14,133/2021, a Brazilian public agency's software procurement starts with planning: a preliminary technical study that justifies the need and compares solutions, followed by terms of reference describing what will be delivered and how it will be accepted. Then come vendor selection and contract oversight.
In software projects, the quality of that planning is what most determines the outcome. Terms of reference that set requirements for accessibility, data protection, activity logging, delivery rituals and acceptance criteria give the contract inspector something to measure and the vendor something to deliver. This text is a general guide: each agency's details follow its internal rules and the guidance of its legal counsel.
How public software procurement works under Law 14,133/2021
Brazil's new public procurement law organizes procurement in phases. The first, the preparatory phase, is where the agency plans: it describes the need, studies the alternatives, estimates the value, assesses the risks and sets the rules of the competition. Next comes vendor selection and, after signing, contract execution, overseen by a designated contract manager and inspectors.
The law also emphasizes the annual procurement plan, risk management and segregation of duties, so that the people who plan, judge and oversee are not always the same. The procurement method and the award criterion depend on the object and are defined by the procurement department with support from legal counsel.
In software, there are two very different situations. One is contracting the use of a system that already exists, as a license or cloud service. The other is contracting the development of a custom system for the agency. Planning changes considerably from one to the other, and the preliminary technical study is the right place to make that choice.
The preliminary technical study comes before everything
The preliminary technical study, known in Brazil as the ETP, is the document showing that the procurement makes sense. It describes the problem to be solved, surveys the possible solutions on the market, compares the paths and justifies the choice. It is also where the agency estimates quantities and identifies the requirements that will guide the terms of reference.
For software, a good ETP answers practical questions: which routine the system needs to support, who will use it (public servants, citizens, management), which systems it needs to talk to, what personal data it will process and whether a market solution works or the case calls for development. Listening to the people who run the process every day, at this stage, avoids terms of reference written only around the tool someone already knows.
This survey has a lot in common with what we do in the initial study of a private project, and the reasoning in how to define the scope of software applies here too.
What software terms of reference need to include
The terms of reference are the document the vendor will comply with and the inspector will measure against. For a system, they need to cover at least:
- Object and need. What will be procured and which problem of the administration it solves, tied to the conclusions of the ETP.
- Functional requirements. The routines the system needs to support, described by what the user does, not by the technology.
- Non-functional requirements. Accessibility, security, data protection, performance, availability and activity logging.
- Execution model. How the work will be organized into deliveries, at what pace and with which test and production environments.
- Acceptance and measurement criteria. What must be working for each delivery to be accepted and how quality will be assessed.
- Ownership and transition. Who owns the code and documentation, how the data is returned and how the system passes to another team at the end of the contract.
- Warranty and support. How long the vendor fixes defects and how support tickets work after delivery.
Ownership deserves special attention. Law 14,133/2021 provides, as a rule, that in software development contracts the economic rights be assigned to the public administration, and the terms of reference should address this together with the delivery of code and documentation. The topic is covered in detail in who owns the code of custom software.
Accessibility, LGPD and activity logging
Three requirements show up in practically every public system and should be in the terms of reference as requirements, not recommendations.
The first is accessibility. Brazil's Inclusion Law makes accessibility mandatory on websites maintained by government bodies. In practice, systems follow eMAG, the Brazilian e-Government Accessibility Model, and the international WCAG guidelines from the W3C. It is worth asking the vendor to review accessibility in the design, before it becomes code, and to test with a screen reader and keyboard navigation before each delivery.
The second is the LGPD, Brazil's data protection law, which has specific rules for data processing by public authorities. The system must process only the data needed for its purpose, with role-based access control, and the contract must define the vendor's role in processing that data.
The third is activity logging: who did what, when and on which record. In a public system, this history is what makes it possible to answer a freedom of information request, a question from internal audit or a complaint from a citizen.
In Ágil Cidadão, our citizen service system, every update to a request is logged with author, date, message and attachment, management defines by role who sees each service and the interface uses accessible components. These are examples of how these requirements become concrete features.
Delivery and acceptance rituals for the system
Software contracted as a single delivery at the end of the term is the highest-risk scenario for the agency: the problem only shows up when there is no time left to fix it. The law provides for provisional and final acceptance of the object, and the terms of reference can organize development into partial deliveries, each with its own acceptance.
A ritual that works well has four moments: plan what goes into the cycle and the acceptance criterion for each item, show the system working at the end of the cycle, let the agency's team test it in a staging environment and formally record acceptance or open issues. It is the same logic as the sprints with demos we describe in how we work.
The clearer the acceptance criterion, the less room for dispute at acceptance. "The citizen can open a request on a phone, attach documents and receive a protocol number" is verifiable. "Modern, intuitive protocol system" is not.
Documentation for contract oversight
The contract inspector needs evidence to certify each delivery, and that evidence should be produced during execution, not assembled in a rush at the end. The terms of reference can require the vendor to provide, with each delivery:
| Document | What it shows | Why it matters to the inspector |
|---|---|---|
| Delivery report | What was done in the cycle, tied to the items in the terms of reference | Lets the inspector check what was executed against what was contracted |
| Acceptance record | Approved items, open issues and who approved | Supports acceptance and the release of payment |
| Release notes | What changed in the system with each release | Helps trace defects and answer questions |
| Technical documentation | Architecture, installation, integrations and access | Ensures continuity of the system at the end of the contract |
| Accessibility and security report | Tests performed and issues fixed | Proves compliance with the non-functional requirements |
Vendors that already document decisions, versions and risks as part of their method deliver this evidence with no extra effort. When evaluating proposals and at the contract kickoff meeting, it is worth asking for examples of this material. If the question is what a custom system involves, the custom software development page summarizes the workstreams of a project.