Available for select engagements
I’m Alberto Rossotto, a freelance software architect and engineering manager helping ambitious product teams turn complexity into clear, sustainable progress.
Based in Athens
Working worldwide
01 / The short version
I partner with founders, product leaders, and engineering teams at moments that matter: a platform needs direction, delivery has slowed down, or a team is ready for its next chapter.
My role flexes between architect, hands-on engineer, and manager — always focused on making the next decision clearer and the work more durable.
02 / Selected work
01↗
A mission-critical application was running on an end-of-life NoSQL database, with an incompatible replacement as the only way forward. I designed a “shadow production” approach that let us migrate 50+ verticals with no disruption to production.
Read the story ↗
02↗
A payment service saw long quiet periods and sudden spikes. I split fast validation from slow processing, so users get an instant answer and the heavy work runs asynchronously and scales on its own.
Read the story ↗
03↗
A product with a separate deployment per customer was buried in feature flags and custom code. I redesigned it around a lean core, extension hooks and an SDK, so each customisation became a plugin instead of more complexity in the core.
Read the story ↗
04↗
An early-stage fintech needed to close the gaps left by a rushed MVP. I led pen-testing, GDPR compliance and the technical side of an FCA audit, which ended with only minor, mostly non-technical remarks.
Read the story ↗
05↗
I designed the exit plan and then executed it: customers refunded or transferred, data preserved in cold storage, and the team informed at every step, so the business closed in a responsible and controlled way.
Read the story ↗
06↗
The level 1 service desk couldn’t route incidents correctly, so teams were paged needlessly and fixes were slow. A symptom-based decision guide now gets the right team, at the right priority, on the right incident, and it reduced MTTR.
Read the story ↗03 / How I help
Pragmatic direction for systems that need to scale without losing their shape.
Hands-on support for managers and teams navigating growth, change, or uncertainty.
Better ways of working that turn good intentions into consistent, visible progress.
04 / Get in touch
Share what you’re building, where the pressure is, and what success looks like.
The challenge
A complex application with 50+ verticals ran on an end-of-life NoSQL database, and the only way forward was a new, incompatible one. The migration had to include the data itself, with no disruption to production or to the downstream services that depended on it.
The approach
We started with the market: we shortlisted the leading candidates across both SQL and NoSQL and ran a quick proof of concept on each to find the best fit.
For the migration itself, I proposed a “shadow production”: a parallel environment fed with the same input as the live system, so we could compare the two outputs continuously before switching anything over.
Verticals moved one by one, starting with those that had no dependencies and progressing to those whose dependencies had already been migrated.
The outcome
The shadow approach reliably surfaced differences between the old and new platforms. A fix-or-accept policy kept the effort focused: real defects were fixed, and minor inconsistencies were consciously accepted. Production was never disrupted. The cost of that safety-first approach was time, and the project ran longer than first planned.
The challenge
The service was part of a larger payments flow. Traffic was low and flat most of the time, with occasional sharp bursts when events triggered high volumes. It had to stay responsive and scale through those peaks.
The approach
We split the flow in two: a fast validation path and a much slower transaction-processing path. A synchronous API module validates each request, gives the user immediate feedback and enqueues the work for a separate processor module.
Requests are queued by customer identifier, so concurrent requests from the same user are serialised out of the box.
The outcome
Users get a fast acknowledgement while processing happens asynchronously. The design absorbs traffic spikes and makes the service simpler to scale. Queuing by customer identifier also removed race conditions and most of the slow synchronisation logic, which kept the internals simple.
The challenge
The product was a monolith deployed separately for each customer, with feature flags enabling the features each one needed. Configuration and customisation code kept growing, and testing suffered.
The approach
We identified the application’s core flow and added hooks for extensions. Each extension acts as a filter that can modify the partial result before control returns to the core.
We built an SDK for creating pluggable libraries, which can be dropped onto the filesystem and loaded dynamically by the core.
The outcome
The core became more linear, and customer-specific behaviour moved into clearly identifiable plugins. Configuration complexity turned into a deployment decision: which components to install for each customer. Testing improved too, because the core and each plugin can be validated independently.
The challenge
An early-stage fintech startup had to address what its rushed MVP had left behind: cybersecurity, GDPR compliance and readiness for an audit by the Financial Conduct Authority (FCA).
The approach
The outcome
Every confirmed vulnerability from the pen-test was fixed. We put a process in place for GDPR data-access and right-to-be-forgotten requests, and fixed technical issues that posed a risk. The FCA audit ended positively, with minor, mostly non-technical remarks.
The challenge
A startup was preparing to close its operations and needed a plan to do so responsibly, protecting its customers, its data and its people.
The approach
We started by working out how long it would take to close or transfer every customer account and issue refunds, which set the timeline for the whole process. I designed the plan and coordinated its technical execution. It covered every step, from how to announce the exit to how to decommission the services and move customers elsewhere.
When the time came, we followed the plan step by step with very little improvisation. We informed customers, processed refunds where needed, transferred the remaining customers and archived data to cold storage, tracking progress throughout. Services were scaled down or removed as soon as they were no longer needed, until only an informational website remained.
The outcome
Customers were looked after, their data preserved, and the closure ran in a controlled way. The plan also gave the team clarity: everyone knew the timeline, the earliest date their position could end, and what was coming next, which kept the work calm and focused until the last day.
The challenge
The level 1 service desk lacked the context to diagnose incidents and send them to the right group. The result was unnecessary calls to engineering teams and slower resolution.
The approach
We identified the ten incident types most often misrouted or misprioritised, and built a symptom-and-check guide for the service desk. Each symptom led through at most five yes/no questions to a clear outcome: page a specific team, open a low-priority ticket, or resolve the incident directly with a step-by-step procedure.
The outcome
The most common incidents were turned into email notifications, and calls dropped from a few a day to about one every few weekly shifts. Fewer false alarms made the remaining calls feel as urgent as they were, and handoffs between teams dropped to near zero. The service desk could also resolve the simplest issues on its own.