Public procurement in Bosnia and Herzegovina is governed by the Law on Public Procurement (Official Gazette of BiH 39/14, 59/22 and 50/24), and procedures run through the e-procurement system at ejn.gov.ba. The law sets the procedure, but the quality of what you receive depends mostly on the technical specification. This is the structure I recommend, written from the point of view of a supplier who has read many good and bad tender documents. The same principles apply to donor-funded projects with Terms of Reference.
Short answer
A good specification describes what the portal must enable citizens and staff to do, not which technology to use. It contains a list of pages and functions, requirements for accessibility, speed and security, ownership of the code and domain, maintenance, deadlines and measurable acceptance criteria.
Before writing: market check and real needs
The law provides for a preliminary market check before launching a procedure (Article 14a). Use it: talk to users of the current website, look at what citizens most often ask for by phone or at the counter, and compare portals of similar institutions. Ask several providers for an indicative estimate and document everything. That gives you a realistic estimated value and a specification that matches real needs.
Recommended structure
- Goal and users — who the portal is for and what they should be able to do on it (report a fault, find documents, read notices, use e-services).
- Scope — list of pages and sections, number of languages, migration of existing content (how many pages, news items and documents).
- Functional requirements — what users and administrators must be able to do, described as tasks.
- Non-functional requirements — accessibility, speed, security, data protection, mobile display.
- Hosting and domain — who provides hosting, where data is stored, who the domain is registered to.
- Ownership and documentation — source code, logins, technical and user documentation.
- Training — number of people and format of editor training.
- Warranty and maintenance — warranty period, time to fix defects, optional maintenance after the warranty.
- Deadlines and phases — design, development, testing, migration, go-live.
- Acceptance criteria — how you will verify that what was agreed has been delivered.
Functional requirements: describe tasks, not technology
Instead of “the portal must run on platform X”, write what needs to happen:
- “Authorised staff publish news, notices and documents without a developer’s help.”
- “Citizens can report a fault with location and photo from a mobile phone.”
- “Documents can be filtered by type and year and searched by title.”
- “Works notices appear on the home page while the works last.”
Referring to a specific brand, product or origin restricts competition. If it is unavoidable, add “or equivalent” and describe what the equivalent must meet.
Non-functional requirements worth writing down
| Area | Example of a measurable requirement |
|---|---|
| Accessibility | Compliance with WCAG 2.1 level AA, verified with a tool and a manual keyboard test |
| Speed | Core Web Vitals in the green on mobile for key pages |
| Security | HTTPS on all pages, two-factor login for administrators, regular off-server backups |
| Data protection | Forms collect only necessary data; privacy policy in line with the law |
| Mobile display | Correct display from 320 px width, no horizontal scrolling |
| Search engines | Titles and descriptions for all pages, a sitemap, redirects from old URLs |
More on accessibility and how to check it in website accessibility (WCAG).
Ownership: the most frequently missed item
The institution should receive the source code, all logins (domain, hosting, admin) and documentation, with no lock-in to a single supplier. The domain is registered to the institution. If this isn’t in the specification, three years later you may find that nobody but the original supplier can maintain the portal.
Acceptance criteria
Before signing the handover record, check that every function in the specification works, the speed and accessibility test results, that content was migrated and old URLs redirect to new ones, that editors were trained and that you received the code and all logins. State in the specification that delivery is complete only when all criteria are met.
Award criterion
The criterion can be the lowest price or the most economically advantageous tender. For web portals, lowest price often means the minimum interpretation of the specification. If you choose lowest price, secure quality through very precise technical requirements and acceptance criteria. Supplier qualification requirements should be proportionate to the contract value so they don’t exclude small, specialised suppliers without reason.
The most common mistakes
- A specification copied from another institution, with functions you don’t need.
- No information on the amount of content to migrate — bids then can’t be compared.
- No deadline for fixing defects during the warranty period.
- Hosting and domain “with the supplier”, without access for the institution.
- No measurable requirements for speed and accessibility.
Note
This guide is a practical recommendation for the content of a technical specification and is not legal advice on running a procedure. For the procedure itself, rely on the Law on Public Procurement, its by-laws and the guidance of the Public Procurement Agency of Bosnia and Herzegovina.
Preparing a portal tender?
As a potential bidder I don’t write tender documents, but this guide and the example requirements are yours to use. See how I approach portals for institutions on the public sector page.
Engimotive · Published October 28, 2026