A tender information portal is not a website. It is the public record of how public money was allocated, and it will be read by bidders who lost, by journalists, by auditors, and eventually by people looking for a mistake. That changes what "done" means.

We have built and maintained tender information portals for infrastructure agencies — the Hanoi MRB portal and the MAUR portal — and this is the requirements checklist we wish every agency put in its specification. It is written for the procurement side: use it to write an RFP, or to grade the proposals already on your desk.

In public infrastructure, transparency is not a feature you add at the end. It is a data model decision you make at the beginning.

Start with the standard, not the screens

The single highest-leverage line in a tender portal specification is the data standard. The Open Contracting Data Standard (OCDS) and its infrastructure extension, the Open Contracting for Infrastructure Data Standard (OC4IDS), define how contracting and project information should be structured and published — identifiers, stages, parties, values, documents. The CoST Infrastructure Transparency Initiative disclosure framework covers what infrastructure projects should proactively disclose.

Specifying a standard up front does three things a screen-by-screen specification cannot: it makes the portal's output machine-readable for oversight bodies, it removes ambiguity from acceptance testing, and it protects the agency from a portal whose data cannot be exported to whatever comes next. If you write nothing else technical in your RFP, write this.

The 12-point checklist

Publication and data (1–4)

  • 1. Structured publication against a named standard. Every tender record maps to OCDS/OC4IDS fields, with a documented mapping. Machine-readable export (JSON and CSV) available without login.
  • 2. Full contracting lifecycle, not just notices. Planning, tender, award, contract, and implementation stages — each with its own publication moment. Portals that stop at the notice stage answer the least interesting question.
  • 3. Document integrity. Attachments are versioned and immutable once published; superseded documents remain retrievable rather than silently replaced. Every document has a publication timestamp.
  • 4. Unique, permanent identifiers. A stable ID per project and per contracting process, and URLs that never change. Broken links in a public record are a transparency failure, not a maintenance detail.

Access and usability (5–7)

  • 5. Search that a bidder can actually use. Filter by status, value band, category, procuring entity, and date range; full-text search across notice text and attachments. Deep-linkable result URLs so a filtered view can be shared or cited.
  • 6. Bilingual publication with parity. For Vietnamese agencies, Vietnamese and English versions of the interface and of the metadata, with the language of record stated explicitly so there is no ambiguity about which text governs.
  • 7. Accessibility and low-bandwidth performance. WCAG 2.1 AA as a contractual requirement, keyboard navigation, screen-reader-tested tables, and pages that load on a mobile connection. Accessibility in a public portal is an obligation, not an enhancement.

Trust and operations (8–12)

  • 8. Append-only audit trail. Who published or amended what, and when — retained and exportable. If an amendment can be made without a trace, the portal cannot be used as evidence.
  • 9. Role-based access with least privilege. Separate roles for drafting, approving, and publishing, so publication requires two people. Named administrator accounts only; no shared credentials.
  • 10. Security aligned to a named framework. OWASP ASVS or an equivalent, with independent testing before go-live and after major releases. Rate limiting and abuse controls on public endpoints. Documented data residency. Our security practice covers how this is evidenced.
  • 11. Availability and deadline integrity. An availability target with a stated measurement method, and server-side timestamping for submission deadlines — never client clocks. Publish a maintenance window policy that excludes the days before a closing date.
  • 12. Handover and exit. Source code and infrastructure-as-code in the agency's repository, administrator runbook, data export in the standard's format, and a defined support window. The agency must be able to change partners without losing the record.

What we learned building these portals

Three things surprised us the first time, and now shape how we scope this work:

The hardest part is publication workflow, not publishing. The technical act of putting a notice online is trivial. Designing the approval chain so that a busy officer can publish correctly under deadline pressure — and cannot publish incorrectly by accident — is where the real design effort goes.

Historical data decides adoption. A portal that starts empty gets treated as a side system. Migrating past tenders, even imperfectly and clearly labelled as legacy records, is what makes it the place people check first.

Bidders are a user group with their own needs. They arrive on deadline day, often on mobile, looking for one document. Optimizing that single path — find the tender, confirm the deadline, download the pack — does more for the portal's reputation than any dashboard.

Red flags in vendor proposals

  • No mention of a data standard, or a promise to "export to Excel" instead of standardized publication.
  • Audit logging described as an optional module or a later phase.
  • A CMS demo instead of a data model. Ask to see the schema, not the theme.
  • No named security testing before go-live, or testing performed only by the builder.
  • Hosting and repositories owned by the vendor, with agency access granted rather than the reverse.
  • Accessibility described as "responsive design". These are unrelated requirements.
  • No answer for who operates the portal in year three.

Frequently Asked Questions

What is the difference between OCDS and OC4IDS?

OCDS — the Open Contracting Data Standard — structures data about a contracting process: planning, tender, award, contract, and implementation. OC4IDS extends the approach to infrastructure projects, covering project-level information across the delivery lifecycle rather than a single contracting process. Infrastructure agencies typically need both perspectives: project-level disclosure and process-level contracting records.

Do we need to publish everything, including commercially sensitive information?

No, and a good portal makes the exclusion explicit rather than invisible. The design pattern is to publish the record with named redactions and a stated legal basis, so a reader can see that something was withheld and why. Silent omission is what erodes trust; documented redaction does not.

How long does a tender information portal take to build?

For a single agency with a defined disclosure scope, the specification and data-model stage typically runs three to five weeks, with first production release a few months later depending on how much historical data is migrated and how many approval roles the workflow must support. The data standard mapping and the migration are the two variables that move the timeline most.

Can we build it on an existing CMS?

Partly. A CMS can manage pages and documents, but a tender portal's core is a structured contracting record with an audit trail and standardized export — that belongs in a data model, not in page content. The workable pattern is a purpose-built contracting data layer with a familiar editorial interface on top.

Who should own the source code and hosting?

The agency, in every case. Repositories, cloud accounts, and domains in the agency's name, with the delivery partner granted access. This is the single clause that determines whether you can change partners later without losing the public record.

Writing or reviewing a specification?

If your agency is preparing a tender portal procurement, we are glad to review a draft specification against this checklist — including when the conclusion is that your existing system needs a data layer rather than a rebuild. See our public sector practice for how we work with agencies, or get in touch.