How to write a TDR to procure custom software

In a public software procurement, the document that carries the most weight isn't written by the vendor: you write it. The TDR — Terms of Reference (TDR) — defines what you are going to procure, and a badly written TDR is the number-one cause of projects that get more expensive halfway through, end up as a system nobody uses, or get stuck in litigation. The good news: writing a good one isn't hard, it's method. This is the practical guide — from the experience of having built the cashier system of a national university in compliance with public-sector requirements.

First: TDR or technical specifications — don't pick the wrong document

Custom software is a service, not a good. Its requirement is captured in a TDR (Terms of Reference), not in technical specifications (EETT), which are for goods. Picking the wrong document throws the whole process off from the start.

In Peruvian public procurement the rule is simple: a requirement for goods is captured in technical specifications, and one for services and consultancies in terms of reference. Developing a custom system is a service — which is why the correct instrument is the TDR. It looks like a formality, but it defines the type of process, how bids are evaluated and what you can require. Starting with the wrong document forces you to redo everything.

The framework changed in 2025: Law 32069 and the OECE

Since April 22, 2025, Law No. 32069 has been in force, repealing the old Law 30225 and replacing the OSCE with the OECE. Its guiding principle is “value for money”: the best purchase isn't the cheapest, but the one that delivers the most benefit per sol. Your TDR is written under that framework.

The General Public Procurement Law (Law No. 32069), with its regulations approved by Supreme Decree 009-2025-EF, changed the language and priorities of the system. The long-standing OSCE gave way to the OECE (Specialized Agency for Efficient State Procurement), and the focus shifted to value for money. For software this is liberating: it gives you a legal basis to not award to the lowest price — which in development almost always turns out expensive — but to the bid that best solves the problem.

The golden rule: describe the problem, not the solution

The best software TDR describes the problem and the expected outcomes, it doesn't dictate the technology. Over-specifying (“it must be in such-and-such language, with such-and-such framework”) reduces competition and ties you to a worse solution. The law also requires the requirement to enable broad participation by vendors.

The most common mistake is copying another entity's TDR and filling it with arbitrary technical requirements. Every “it must be built in X technology” that doesn't answer a real need does two bad things at once: it reduces the number of vendors that can bid and it ties you to a technical decision that may not be the best one for your case. Describe which processes you need, which users, which systems it must integrate with and what outcome you expect — and let the expert propose the how. It isn't just better engineering: it's what the regulation asks for when it requires drafting that is clear and doesn't restrict competition.

What a software TDR SHOULD pin down

Pin down the what and the conditions, not the technical how: functional scope by module, required integrations, complete deliverables (including the source code), intellectual property, warranty, training and objective evaluation criteria. Anything not in here will show up later as an “add-on.”

The clause that protects you most: ownership of the code and the data

Require in writing that the source code, the documentation and the data are property of the entity upon completion. It's the difference between having an auditable asset any vendor can continue, and being captive to one that can raise the price or disappear. A good vendor has no problem signing it.

It's the cheapest clause to write and the most expensive to leave out. If, when the contract ends, the code isn't yours, every future change depends on the same vendor, at their price and their pace — and if they raise the rate, discontinue the service or simply vanish, your operation is trapped. It's the same underlying logic that separates custom software from off-the-shelf: custom is justified, among other reasons, because the system is your asset. That principle has to be written into the TDR, not assumed.

Integrations: the point most underestimated (and worst priced)

If your system must connect with the State (RENIEC, SUNAT, SUNARP) or with your ERP, declare it explicitly in the TDR. Integrations —via PIDE or with an ERP like SAP— are the line item that varies most between bids and the one that generates the most “add-ons” when it's left out.

Connecting with other systems is usually the most expensive and underestimated part of a project. The Peruvian State exposes services through the State Interoperability Platform (PIDE), already used by more than 450 entities to exchange data with RENIEC, SUNAT, SUNARP and Banco de la Nación. If your system needs, for example, to validate identity in real time against RENIEC or connect with your ERP for invoicing, that has to be in the TDR by name. Leaving it out doesn't make the integration cheaper: it just turns it into an unforeseen “add-on” — and into a half-built system. Integrations are specified, not taken for granted.

The mistakes that inflate or sink the project

A good TDR attracts serious vendors and produces comparable bids; a bad one drives the good ones away and makes everything more expensive. The difference is in describing the problem (not tying down the technology), pinning down code ownership, spelling out the integrations and evaluating by value, not just by price.

Mind the data: Law 29733

If the system processes personal data —and almost all of them do—, the TDR must require compliance with Law No. 29733 on Personal Data Protection: secure processing, a declared purpose and the vendor's responsibilities over the information.

An enrollment, collections or paperwork system handles people's data. Law No. 29733 mandates careful handling of that data, and the TDR is the place to pin down responsibilities: what data is processed, for what purpose, how it's protected and what happens to it when the contract ends. Written from the start, it's a clause; discovered at the end, it's a legal problem.

How we do it with public entities

We build software for the public sector in compliance with the functional and technical requirements it demands. We can help you make your TDR technically sound and truly comparable across bids — without tying you to any vendor, ourselves included.

For a national university we built its central cashier: receipt issuance with real-time validation against RENIEC, dashboards for senior management and reports for the Treasury — meeting public-sector requirements. That experience lets us see a TDR from both sides: that of the entity that needs to buy well and that of the vendor who's going to build. If you're about to launch a process, we'll review your TDR at no cost and tell you where it's weak — even if in the end you don't hire us.

In short

The TDR isn't a formality: it's the blueprint of your purchase. Pick the right document (TDR, not EETT), draft it under Law 32069 with value for money in mind, describe the problem instead of tying down the technology, and put in writing what really protects you — the deliverables, ownership of the code, the integrations, the warranty and the handling of the data. A good TDR doesn't just comply with the regulation: it makes good vendors want to bid and finally makes their offers comparable. That's where a project that ends well begins.