I study data science at Ca' Foscari in Venice and build things alongside my degree.
The part I enjoy most is the unglamorous middle: getting messy data into one clean shape, putting a model behind a screen people actually use, and checking that the whole thing still works when something goes wrong.
Below are two projects I built end to end. Each one says plainly what state it's in.
Work
Vet clinic data integration
VET_INTEGRATION · prototype · data pipeline + web app
Problem
Veterinary groups that grow by adding clinics inherit a different management system at each site. Bookings, patients, stock and staff end up in separate exports with different column names. Nobody can see the whole group in one place, and every new clinic means another round of manual spreadsheet work.
What I built
A data pipeline that maps each clinic's CSV and Excel exports into one shared PostgreSQL database, and a Flask web app on top of it: an operations dashboard for managers and a "Clinic Hub" for staff.
How it works
Each clinic gets a config file that says which source column feeds which field. Adding a clinic means writing a config, not new code.
The pipeline cleans and normalises the data, then loads it with stable keys, so re-running it never creates duplicates.
After every load it checks row counts against the source, required fields, duplicates and links between tables, and stops if anything is off.
The app is role-based: managers see bookings, staff, leads and inventory per clinic. Front-desk and clinical staff see only the Hub, with announcements, guides and tasks for their role.
Built as a prototype and run end to end on synthetic demo data (no real clinic or patient data). The full stack starts with one Docker command, and a test checks that each role sees only what it should. Next step: an assistant that answers staff questions from the clinic's own guides. A Gemini-based version is drafted; the live app currently uses keyword search.
Links
Code is in a private repository, available on request.
Lead Processor
Lead_Processor · personal project · backend + client dashboard
Problem
Small businesses that run ads or contact forms get leads from several places at once. Replying fast and following up consistently is manual work, and the people who answer get lost among the ones who don't.
What I built
A lead-handling pipeline that started as an n8n workflow and was rewritten in Python with FastAPI. It takes leads in, sorts them, sends a first email and a follow-up sequence, and when someone replies, reads the conversation and summarises what they actually said. The dashboard is multi-tenant, so each business using it would see only its own leads.
How it works
Leads arrive from Facebook Lead Ads (signature-verified), website or Zapier/Make forms, or an Excel upload that runs in a background queue.
A simple, transparent rule set scores each lead as hot, warm or cold. Hot leads trigger a Slack or email alert.
Claude drafts the first email from basic lead details only. Six follow-ups are scheduled inside business hours and stop as soon as the lead replies.
Replies come back through a Postmark webhook. A second step reads the whole thread and has Claude pull out insights based only on what the lead wrote.
Python · FastAPI · SQLAlchemy + Alembic · Redis / Arq · Claude API · Postmark · Docker
Ads · forms · Excel
Validate + score
First email + follow-ups
Reply webhook
Thread summary + alert
Lead flow, drawn from the code.
Outcome
Personal project. The pipeline is covered by 54 automated tests, and the dashboard runs on generated demo leads. It was tested end to end and offered to businesses, but it hasn't been adopted by one.
Links
Code is in a private repository, available on request.