← Blog Blog / Building a Public Procurement Analytics Tool with AI

Building a Public Procurement Analytics Tool with AI
A Weekend Project

A few weeks ago I decided to combine that with something I had been curious about: Greek public procurement data. The question was simple. Can a single developer, using AI tools, build a meaningful analytics platform over a dataset that would normally require a full data team? The short answer is yes. Here is how it went.

The Data

Greece runs two public procurement databases that are open to anyone with an internet connection:

Diavgeia (Διαύγεια): a transparency register launched in 2010. Every public body decision goes in here, including contracts. The idea was ahead of its time. The execution had a structural limitation: the financial fields (amount, contractor, date) were optional. Organizations uploaded the required PDF but left the structured data empty. The result is that a large portion of records have no usable numbers — the document exists, the data does not.

KIMDIS (ΚΗΜΔΗΣ): a newer, mandatory electronic procurement system that reached full operation in 2025. This one was built differently. It is a transactional system: you cannot register a contract without completing all the structured fields. The result is a remarkably clean dataset. Across 124,655 award records, price fields have 0% NULL values. Every record has a verified amount, a contractor VAT number, and a publishing organization.

That design difference, optional fields vs. required fields, is the entire story of why one dataset is analytically useful and the other is not. It is a lesson worth carrying into any data infrastructure project.

What I Built

Over roughly a weekend of work (with significant AI assistance) I built:

  • A harvester that pulls all KIMDIS awards and procurement notices via the official REST API
  • A cleaning pipeline that filters cancelled records, validates price consistency, and removes extreme outliers
  • A statistical analysis tool: procedure type breakdown, top buyers and contractors per procedure type, and an interactive VAT lookup that profiles any organization or explores transactions between two specific parties

The full code is on GitHub: github.com/DimitrisTsak/kimdis_analytics

Anyone can clone it, run three commands, and have the same dataset and analysis on their own machine. No API key needed. No special access. The data is public by law.

What the Tool Shows

A few things stand out when you explore the data:

The most common procedure type by far is direct assignment (Απευθείας ανάθεση), used in 83.9% of all awards and totalling €1.14 billion. This is the procedure used for smaller contracts that do not require a competitive tender. Understanding its distribution across organizations, suppliers, and amounts is the starting point for any deeper analysis.

The interactive VAT lookup is the most useful part for exploration. Enter any VAT number and the tool tells you whether that entity appears as a buyer, a contractor, or both, showing their full counterparty list sorted by value. Enter two VAT numbers separated by a dash and you see every individual award between those two specific organizations, with amounts and titles.

The Role of AI

I want to be precise here because the word gets overloaded. The statistical analysis is not AI. It is SQL queries and Python scripts running against a SQLite database. What a large language model contributed was:

  1. Speed of iteration: the harvesting code, database schema, and analysis scripts were written and debugged in hours rather than days. Debugging API edge cases (rate limits, encoding issues, pagination quirks) that would normally take an afternoon to trace took minutes.
  2. Structural thinking: talking through the data model, the cleaning logic, the right way to handle NULLs and cancelled records, worked better as a dialogue than as solo documentation-reading.
  3. Accessibility: I am a civil engineer, familiar with coding but I had not worked with procurement data or this specific API before. AI compressed the learning curve dramatically.

The tool in its current form is pure data engineering, structured queries over structured data. But the same database becomes significantly more interesting when combined with an LLM tool. A language model sitting on top of this SQLite file could answer natural language questions ("which municipalities spent the most on IT in 2026?"), cross-reference award titles with the actual contract PDFs published on Diavgeia, detect anomalous patterns across thousands of records at once, or cluster organizations by procurement behavior. The foundation with clean, structured, machine-readable data, is already there.

Why KIMDIS Matters

I want to end with something that is easy to miss in a tool-focused post: the quality of KIMDIS is not accidental.

Someone made a deliberate architectural decision to make structured fields mandatory. Someone decided to provide a clean, well-documented REST API. Someone decided to keep historical data accessible and paginated consistently. These decisions are what made this weekend project possible. Without them, this analysis would have required months of PDF parsing, data cleaning, and institutional access requests. KIMDIS is a model of how public data infrastructure should work. If you are involved in designing similar systems the lesson is straightforward: required fields over optional ones, structured data over document uploads, open APIs over data-on-request.

Good data infrastructure is invisible when it works well. This is a case where it worked well.

The code, database schema, and setup instructions are at: github.com/DimitrisTsak/kimdis_analytics
All data sourced from the official KIMDIS open data API (eprocurement.gov.gr). No proprietary data, no scraping, no terms of service violations.