Project
Astika
LiveEvery Italian judicial property auction, in one place and in plain language. Three court portals crawled around the clock, the paperwork read by LLMs, and each auction scored 0–100 with the reasoning shown rather than asserted.
What it is
When an Italian property goes to auction, everything a buyer needs to know exists, and none of it is usable: three portals that do not agree, and the facts that decide the bid buried in an appraisal, a notice of sale and a judge’s order — all of it as PDFs. So people buy blind, or pay someone to read it for them.
Meanwhile the prices are roughly a third of the open market, and the buyers are mostly families looking for a first home, not the investors everyone assumes.
Astika reads all of it and turns each auction into something you can compare: structured characteristics, and a verdict that shows its evidence instead of asking to be trusted.
The numbers
What it handles
- 3 court portals crawled The Ministry of Justice PVP, Astalegale, Astegiudiziarie
- 61,508 auctions indexed 18,732 of them open right now
- ~570k photographs stored plus ~130k normalised addresses
- 2h between crawls with a full re-sync every twelve
What it took to build
- 7 repositories crawlers, import, extraction, scoring, web, chat, docs
- ~641k lines of code across roughly 2,700 commits
- 96 Claude Code skills the part that made the rest repeatable
- 1 person driving it the architecture, the code, and the mistakes
Measured August 2026. No user or revenue figures on purpose — I only publish numbers I can stand behind.
How it works
Five stages, each one its own service, joined by queues rather than by calls. Python crawlers at the front, TypeScript and React the rest of the way, three Postgres databases in between. The compute runs on AWS; Google supplies geocoding, and one of the three model families the extraction is benchmarked against.
-
Scrape
Headless browsers walk three portals that were never meant to be read by machines — a delta pass every two hours, a full sync every twelve.
-
Import
The same property is often listed on all three portals, described three different ways. Here it becomes one record: one set of photographs, and one address, resolved against the municipality register and geocoded through Google’s Maps API.
-
Extract
The facts that matter are not in any field — they are in the appraisal, the notice of sale, the judge’s order. LLMs read the PDFs and return structured data with the sentence each fact came from.
-
Score
Eleven factors, each green, amber or red, each carrying the verbatim evidence for its colour. The 0–100 verdict on top is computed from them in code.
-
Publish
The web app: search, comparison, and an auction page that reads like a listing instead of a court document.
The one decision I would defend hardest: the model reads and cites, the code decides. A model finds the sentence that says a property is occupied; it cannot reliably tell you what that is worth — so the verdict is never asked of the model, and it comes out the same every time.
Two things that were genuinely hard
Building it at all, ten years after I stopped
The story people expect is “someone who could not code learned to code with AI”. It is not this one, and pretending otherwise would be flattering myself in the wrong direction.
-
I wrote the code
The sole developer at LeadsBridge — I wrote the first version myself, in PHP and MySQL on AWS, and it grew into 400+ integrations used daily by 2,500+ customers.
-
I stopped writing the code
CPO at LeadsBridge through the acquisition, then ActiveProspect, Workato’s $37M ARR embedded platform and PandaDoc — ten years of deciding what got built, and none of building it.
-
I write the code again, differently
Astika. Not by typing it but by directing it: the architecture rather than the diff, ruthless about what a model gets wrong on its own.
The real question was whether the years in product had cost me the ability to ship, or given me the only thing that makes directing a model work: knowing what to ask for, and recognising when what came back is wrong.
Keeping the interface consistent
This is the failure mode of AI-built frontends, and nobody warns you about it: every session invents a slightly different button, a slightly different spacing, a colour that is nearly right. Individually invisible; collectively, six products.
The fix was not a stricter prompt. It was writing the design system as fourteen skills, one per surface that kept drifting, plus a lens skill that refuses invented colours, or a new component written before searching for the one that already exists.
When a new area starts drifting, the answer is another skill — not another apology for the same mistake.
What it cost me to learn
- One Database, One Repo: Why Multi-Repo Hurts AI Coding
This one is about Astika, and it is not flattering: splitting the system across repositories cost me months in duplicated code and handover files. I would not do it again, and I say so.
- UI Thrashing: The Reset Protocol That Actually Works
What to do when an AI-driven interface session turns into an endless loop of micro-tweaks. The answer is not to keep negotiating with the model.
- The Skills I Actually Kept
Which of those 96 skills earned their keep, and the rule I use to decide whether to write one at all.
One warning before you click
Everything on astika.it is in Italian — the auctions, the courts, and very much the PDFs. Bring a translator, or just look at the shapes.