Work with me

I'm Luca Palonca — 7+ years a software engineer, currently Backend Tech Lead on a US healthcare SaaS platform, working from Italy. Across those years I've migrated 51M records with zero downtime, taken an API from 8 seconds to 350ms, and more recently built guardrails and evals over 2M+ clinical documents with 3.5M+ LLM requests under cost and rate-limit control. I co-authored a peer-reviewed paper on time-series anomaly detection (Springer, 2020). More about me →

Backend architecture and performance

Services and the APIs in front of them, data models, query performance, and the scaling and cost problems that show up once real traffic arrives. Usually this starts as either "this is slower and more expensive than it should be and nobody has had a clear week to prove why", or "this works fine now and won't survive what we're about to put through it".

• A backend that's quietly become slow or expensive, profiled and fixed rather than described
• A design or data-model decision reviewed before you commit to something painful to undo
• A service and its API, built properly, when your team is at capacity

Migrations and data pipelines

Moving data between shapes without taking the platform down, and the ingestion and processing pipelines that have to keep up afterwards. The load-bearing property is almost always idempotency — safe re-runs are what turn "the job failed at 2am" from an incident into a non-event.

• A migration that has to run against live operational data with no downtime
• An ingestion or processing pipeline that needs to keep pace with real volume
• A manual, per-customer process that should be an automated one

Making AI features reliable

The part that sits on top of a backend rather than replacing it. Most accuracy problems in production LLM systems turn out not to be model problems — they're retrieval, grounding, and the absence of any way to tell whether last week's prompt change made things better or worse.

• A feature that fabricates specifics, cites nothing, or answers differently every run
• A prototype that demos well and nobody is willing to put in front of customers
• An eval harness and golden set, so a bad prompt or model change fails before it ships

How I work

• One engagement at a time. I do this alongside a full-time role, so I take one piece of work and finish it rather than running three in parallel. If that means you wait, you'll hear the date up front rather than afterwards.
• Written first, calls where they help. Deliverables and answers arrive in writing, and I'm happy to get on a call to walk through them. What I don't do is standing meetings — no standups, no weekly sync, no recurring slot in your calendar.
• Code, not just documents. Reviews and audits ship pull requests against the top findings. A list of recommendations nobody schedules isn't worth what you'd pay for it.
• Scope agreed in writing, before the work. If something turns out bigger than we agreed, you hear about it while you can still decide.
• Based in Italy, overlapping the US morning. Enough overlap to unblock you the same day; not enough to sit in your standup, which suits us both.

Getting started

Tell me what you're building or what's breaking. You'll get a written read on it within two business days — what I think is actually going on, what I'd do about it, and what it would take. If it isn't something I'd be good at, I'll say so.

Or book 20 minutes if you'd rather talk it through.