Skip to content

Gabriele
Chibbaro

Software & AI Solutions Architect

The architecture decides whether it survives the second year.

I work where systems stop being simple: scale, unclear design, and models that have to run in production and not only in a notebook.

Available for new projects

Got something
worth building?

Let's build it properly.

Download CV

Italy · remote across the EU

  • C# C#
  • .NET
  • Java
  • Python
  • FastAPI
  • Node.js
  • Blazor
  • Angular
  • React
  • Astro
  • Tailwind
  • Flutter
  • TypeScript
  • PyTorch
  • TensorFlow
  • scikit-learn
  • Pandas
  • OpenCV
  • ML ML.NET
  • Docker
  • Kubernetes
  • GitHub Actions
  • AZ Azure
  • PostgreSQL
  • SQL SQL Server
  • MongoDB
  • 5+

    Years on production systems

  • 10+

    Projects delivered

  • 4

    Companies collaborated with

  • 1

    Patent co-authored

About

Where my work starts

I work where the architecture decides the outcome — financial platforms that cannot lose a transaction, medical AI that has to hold up to clinical scrutiny, enterprise software that has to keep running while it changes.

That work starts where things stop being simple: the product that served ten customers and breaks at a hundred, the model that scores well on a held-out set and has never seen a production request.

About
Based in
Italy · remote across the EU
Domains
Fintech and accounting, healthcare AI, enterprise platforms
Building
Leaf — modular business platform · Glide — workflow engine
Open to
Consulting · architecture reviews · AI projects

What I do

Six things I get called in for

Not a service menu. These are the shapes the work actually takes once the problem is on the table.

01

Architecture

Bounded contexts that match how the business actually works, and API contracts that outlive the teams behind them.

  • DDD
  • Bounded contexts
  • API contracts
02

AI & ML

Custom models, the pipelines that feed them, the serving layer that keeps them answering. The model is the small part.

  • Custom models
  • Pipelines
  • Serving
03

Cloud & DevOps

Containers, CI/CD and observability sized for the team that has to operate them on a Tuesday afternoon.

  • Containers
  • CI/CD
  • Observability
04

Full-stack

APIs, backends and the interfaces on top, built as one system — the seams are decisions, not accidents.

  • APIs
  • Backends
  • Interfaces
05

Consulting

Assessment, roadmap, technical due diligence. Often the answer worth most is the one about what not to build.

  • Assessment
  • Roadmap
  • Due diligence
06

Performance

Profiling, hardening and load work on systems already live, where starting from a blank page is not an option.

  • Profiling
  • Hardening
  • Load
How I can help

How I work

Start small, grow in modules

The architecture that carries the first customer should be the one that carries the hundredth.

I start from a small piece that works in production and grow it. Each module is validated under real load before the next is added, and the trade-offs — cost, complexity, what the team can maintain — get said out loud before they are paid for.

  1. 01

    Understand

    The constraints, the systems already running, and what actually breaks — before a single line of design.

  2. 02

    Start small

    One piece, in production, doing real work. Not a prototype and not a proof of concept.

  3. 03

    Grow in modules

    Each module validated under real load before the next is added. Nothing is built on an unproven assumption.

  4. 04

    Scale

    The same architecture carries the hundredth customer. Growth stops meaning rewrite.

There is no default architecture

For a small team the right answer is often a modular monolith with a single deploy; sometimes it is an event-driven platform on Kubernetes, and sometimes it is a data pipeline with a model at the end. The constraints choose — cost, team size, and what the company already runs.

Modular monolith

Clear internal boundaries, one deployable unit, one database to reason about.

Fits when A small team that needs to move fast without paying the operational tax of distribution.

Service-oriented

Services split along ownership lines, with contracts that are versioned on purpose.

Fits when Several teams whose release cadences have started to collide.

Event-driven

Systems emit events; reactions are decoupled from the thing that caused them.

Fits when Workflows that span tools nobody wants to couple together.

Data & ML pipeline

Ingestion, preprocessing, training and serving, each observable on its own.

Fits when The product is the prediction, and it has to be reproducible.

Selected work

Problems from real systems

Every project here started as a problem on real work, not as a portfolio exercise.

All work

Track record

Where the work has happened

  1. 2024 →

    AI Researcher

    Aigon SRL · ex Gate To Brain

    • Deep learning on medical imaging
    • Multi-modal MRI and genomics
    • Patent co-authored

  2. 2023 →

    Software & AI Architect

    Independent

    • System architecture for finance, healthcare and enterprise clients
    • Machine learning in production
    • Architecture reviews and technical due diligence

  3. 2021 →

    Full-Stack Developer

    Tecnos Group SRL

    • Accounting systems on real financial workflows
    • Reliability, data integrity and performance
    • E-invoicing integration with the Italian Revenue Agency

Stack

Tools I actually ship with

Not everything I have touched — the things I would be comfortable putting in front of a paying customer on Monday.

  • C# C#
  • .NET
  • Java
  • Python
  • FastAPI
  • Node.js
  • Blazor
  • Angular
  • React
  • Astro
  • Tailwind
  • Flutter
  • TypeScript
  • PyTorch
  • TensorFlow
  • scikit-learn
  • Pandas
  • OpenCV
  • ML ML.NET
  • Docker
  • Kubernetes
  • GitHub Actions
  • AZ Azure
  • PostgreSQL
  • SQL SQL Server
  • MongoDB

Writing

Notes from the work

Things I had to figure out on real projects, written down while they were still fresh.

· 5 min read

There is no default architecture

Microservices, modular monolith, event-driven — none of these is a starting point. The constraints choose, and the constraints are usually cost, team size and what the company already runs.

  • Architecture
  • Trade-offs
  • DDD

· 4 min read

Research is finished when it runs

A model that only exists in a notebook has not been finished — it has been described. What it takes to close the gap, from someone who works on both sides of it.

  • Machine learning
  • MLOps
  • Production
All writing

Why these projects exist

Three things I keep coming back to

The fix belongs in the system

The reconciliation model went into the platform the operators already used, not into a separate tool nobody would open. A correct answer in the wrong place is not an answer.

Research is finished when it runs

Explainability, preprocessing and deployment are the work, not the afterthought. A model that only exists in a notebook has not been finished, it has been described.

Italian SMEs do not need another ERP

They need the systems they already own to talk to each other. That constraint is the whole reason Leaf and Glide exist.

Have a system that has stopped being simple?

Whether you need an architecture review, a technical partner, or someone to get a model out of a notebook and into production — tell me what is breaking.

Start a conversation More about me