Public procurement of development services – here's what applies
Public procurement of IT development is governed by LOU and must give all vendors equal terms. The key is describing what the system needs to achieve through functional requirements rather than locking in technical details, choosing the right contract form for the need, and setting evaluation criteria that reward quality lawfully, not just the lowest price.
The public sector procures development under the Public Procurement Act, LOU. The rules exist to protect public funds and give all vendors equal terms – but used wrong, they scare off exactly the skilled vendors you want to reach. A requirements catalog with a thousand detailed demands attracts those who are best at filling in forms, not those who are best at building systems. Here’s how to procure development without getting stuck in that trap.
Choose the right contract form for the need
The first fork in the road is about how you buy, not what. Three approaches dominate, and they suit different situations.
- Direct procurement applies below a value threshold and requires no advertising. It suits contained efforts like a feasibility study or a short consulting engagement. Remember to calculate the full need – you can’t split a large purchase into small pieces to avoid advertising.
- Framework agreements give you a negotiated set of vendors and terms, often for up to four years. Convenient for recurring call-offs, but the market freezes at signing – a concern in an industry where expertise and price move fast.
- Dynamic purchasing systems keep the door open: new vendors can join throughout the system’s lifespan. That gives you a fresher vendor base for IT expertise, at the cost of more administration.
The rule of thumb: the more long-term and changeable the need, the more that speaks for an open form over a locked framework agreement.
Functional requirements instead of detailed requirements
The biggest mistake in public IT procurement is specifying the solution instead of the need. If you write “the system must use framework X and store data in database Y,” you’ve already decided the architecture – often without being the one who knows it best.
Describe instead what the system needs to achieve. Instead of “search function built in technology Z,” you write “a caseworker must be able to find a case by number or name within two seconds.” Then vendors compete on their expertise, and you get proposals you wouldn’t have thought of yourself. Functional requirements are also easier to follow up on: either the solution meets the two-second target or it doesn’t, while a detailed requirement on technology choice rarely says anything about the outcome.
Don’t mix up requirements that are mandatory with things that are merely desirable. Every absolute must-have requirement you set shuts out vendors – set them only where they’re genuinely needed.
Evaluation criteria that reward quality lawfully
Lowest price is easy to defend but dangerous for development, where the difference between a great team and a weak one is enormous. LOU allows you to weigh in quality – provided you describe how, already in the tender documents.
| Criterion | How to make it legally measurable |
|---|---|
| Team expertise | Score CVs and concrete experience with similar systems, not company size |
| Solution quality | Let the vendor solve a contained test task assessed against predetermined criteria |
| Method and way of working | Request a described delivery plan and assess it against defined success factors |
| Price | Weight it against quality so cheap but weak doesn't win automatically |
The point is predictability: a vendor should be able to work out their own score from your tender documents. Arbitrariness is both unlawful and an invitation for a formal appeal.
A scenario: two ways to ask
A municipality is about to procure a new case management system. In the first version of the tender, 400 detailed field-level requirements are listed. The bids come from vendors used to public forms, and the winner builds exactly what was written – including the thinking errors that were in the requirements list.
In the second version, twenty operational workflows that need to work are described instead, plus a test task. Now smaller, sharper vendors respond too, and the municipality can assess actual competence before signing. Same budget, completely different outcome – the difference was in the question, not the money.
A well-thought-out procurement unlocks quality instead of shutting it out. If you’d like to bounce around your requirements or evaluation model ahead of a procurement, we at Weapp are glad to have that conversation – get in touch with a short description of what you’re buying.
Frequently asked questions
Do we always have to advertise the procurement?
No, not always. Below the direct procurement threshold, you can buy without advertising, but you still need to act in a businesslike way and be able to justify the choice. Above the threshold, advertising is required, either as a standalone procurement or through a call-off from an existing framework agreement. Add up the full contract value, not just the first year, when you assess which rules apply.
What's the difference between a framework agreement and a dynamic purchasing system?
A framework agreement freezes vendors and terms for the contract term, often up to four years. A dynamic purchasing system stays open for its entire lifespan, so new vendors can join on an ongoing basis. For fast-moving IT expertise, the dynamic system gives you a more current market, while the framework agreement gives you simpler call-offs.
Can we talk to vendors before the procurement?
Yes. An external dialogue or RFI before you publish the tender documents is permitted and often wise. It helps you write realistic requirements and understand what the market can deliver. The condition is that no single vendor gets a head start – what you learn should benefit everyone in the final documents.
How do we avoid letting price be the only deciding factor?
Use quality as an award criterion alongside price, and describe in advance how you'll score it. Concrete, measurable quality factors like the team's experience with similar systems or an assessed test task hold up legally, unlike loose judgments. Weight price and quality so a cheap but weak proposal doesn't win automatically.