Software architecture and technical leadership for teams that need to move fast.

I started programming in BASIC as a kid in the eighties, on my first Commodore 64. I learned C on an Amiga 500, then studied Pascal and x86 assembly. By the late nineties I was working professionally with Borland Delphi, then C++, Python and eventually Java, which has been my primary language for over twenty years.

I have worked as a researcher in computational geometry and machine learning, as a lead SOA architect at Sun Microsystems for the Italian market, as a solutions engineer at Alfresco supporting the launch of their Italian operations, and as a technical architect at AKQA in Berlin on enterprise digital transformation projects. In 2014 I co-founded SoftInstigate and co-created RESTHeart, an open-source backend platform for MongoDB used in production worldwide.

Having seen the same class of problems from inside a technology vendor, a global digital agency, and a product company I built myself gives me a perspective that is difficult to acquire any other way. I still write code every day. I take on fractional CTO and advisory engagements where that combination of judgment and hands-on experience matters.

You can see my open source work on GitHub.

Depending on where you are:

1. Your system doesn't scale: slow APIs, databases under pressure, infrastructure that requires heroics to keep running.

2. Your team is stuck: decisions that stall, technical debt that nobody owns, engineers firefighting instead of building.

3. You're starting something new: you want to get the architecture right from the beginning.

Architecture reviews, technical leadership, hands-on backend work with Java, MongoDB, AWS, API design. For teams that need a senior engineering voice.

A recurring part of my work sits between business and IT. I help translate business requirements into technical decisions and technical constraints into language that product and leadership can act on. That translation layer is often where projects stall, and it is where I tend to be most useful.

AI works best when it is treated as an infrastructure problem. That means building it on top of what you already have: your data, your processes, your existing systems.

The outcome of AI-assisted development depends on the context you bring to it: knowing which questions to ask, recognizing when the output is wrong, catching architectural mistakes before they compound.

A cross-section of engagements across two decades and several industries:

Get in touch and we can discuss how to get started.