Local AI, not cloud
Using Ollama with local models keeps data inside the infrastructure, removes per-query cost and takes external API limits out of the equation.
case study · Automation & AI
Arce
Monitoring and analysis of public tenders with local AI.
RoleDesign, development and infrastructure — end to endYear2025
Pythonn8nPostgreSQLOllamaLocal AIDockerLinuxWeb scrapingJSON
Arce monitors the publications of the state procurement portal (ARCE), extracts each tender, structures it, analyzes it with an AI model running locally and surfaces only the relevant opportunities for the sales team in a dashboard.
The problem
Spotting opportunities meant manually reviewing the state procurement portal (ARCE): a slow, repetitive process, easy to neglect among everything else. It was about 2 hours a day, 5 days a week.
The information came as unstructured text, hard to compare and filter. When a relevant tender showed up and nobody saw it in time, it was a missed opportunity.
The solution
Arce automates that whole journey. It monitors the latest ARCE publications, extracts each tender, converts it to a structured format and evaluates it with local AI to decide whether it is relevant.
The topic of interest is configurable: in my case it filters by aluminum, my company’s field, but it adapts to any other without touching the code.
The team stops checking the portal: they open a dashboard and see only the opportunities that matter, already filtered and sorted.
architecture
How data flows, from source to dashboard.
01
ARCE (state procurement)
The latest publications of the state procurement portal are the entry point.
02
Python scraping
Scripts that automatically extract each published tender.
03
Structuring
Unstructured text is normalized into consistent, comparable JSON.
04
PostgreSQL
Tenders are stored with a queryable history, without reprocessing everything each time.
05
Local AI (Ollama)
A locally running model classifies and filters each tender by relevance.
06
Dashboard
The team sees only the relevant opportunities, ready to act on.
The whole flow is orchestrated in n8n: adjusting sources, rules or frequency is done on the workflow, without rewriting the system.
technical decisions
Why it is built this way.
n8n to orchestrate
Coordinating the flow in n8n means changing rules, sources or frequency by touching the workflow, instead of rewriting and redeploying code.
PostgreSQL as the base
Storing the structured tenders in Postgres enables querying, comparing and keeping a history, instead of processing everything from scratch on each run.
Everything in Docker
The system runs containerized on Linux: reproducible, isolated and deployable on a private server with no fragile dependencies.
demo
The dashboard in action.
screenshots
Under the hood.
results
~10 hrs
of manual search saved every week (before: 5 days × 2 hrs reviewing by hand).
0
time spent reviewing the ARCE portal manually.
Configurable
the field of interest changes without touching the system (in my case, aluminum).
Got a process that could be automated like this?
If any of this looks like a problem of yours, let us talk.