πŸ‡ΊπŸ‡Έ MIT Sloan πŸ‡¨πŸ‡­ IMD Lausanne 20 years · 10+ industries
Andrei Ursuleanu Andrei Ursuleanu

Every platform has problems the team learned to live with.

They sit between systems. Between teams. Between code and business. Nobody owns them. They are expensive, and they get more expensive the longer they stay.

I find them, build the fix, and make the better path the default.

Why these problems stay expensive

Platform problems persist not because teams are weak. They persist because of how organizations work.

The cost hides in the gap between systems. No single team sees it. No single dashboard shows it. The waste accumulates in default behavior that nobody chose and nobody reviews.
The risk hides in the gap between teams. A migration that depends on hundreds of fragile edits across tenants. One missed line drops production alerts. But the risk is invisible until it breaks.
The fix fails because it stays a one-time repair. Someone fixes the incident. The incident comes back. Nobody changed the default. Nobody built the guardrail. The team goes back to firefighting.
The real problem is not effort. It is visibility, ownership, and the right default. Most platform problems are already known. What is missing is someone who maps the full picture, builds the fix, and makes it stick.

What I do about it

I work on the problems that are already expensive, already crossing team boundaries, and already being avoided. The work is always the same shape: find what is actually broken, build the fix and the guardrails together, and leave the better path easier than the old one.

Platform cost
Infrastructure waste hidden in default behavior. I trace the allocation model, find where the cost actually sits, and redesign the default so the lower-cost path runs without anyone thinking about it.
Reliability and self-healing
Platforms where on-call is heavy and incidents repeat. I build self-healing automation and monitoring standards that make the platform recover without human intervention.
Migration risk
Migrations that depend on fragile per-tenant edits. I replace change-per-entity approaches with configuration models that make the move safe at scale.
Performance under growth
Critical paths that degrade as data grows. I profile, redesign, and build the discipline - budgets, automation, guardrails - so performance stays up even as volume multiplies.
Monolith modernization
Systems where a greenfield rewrite already failed. I build the solution inside the existing system instead of pretending the constraints are optional.
Operational visibility
Money leaking, but nobody can see where. I map the full chain and build the observability layer that makes the loss visible for the first time.

What stays after I leave

The fix outlasts the engagement. The platform defaults change. The team capability grows. The problem does not come back.

Guardrails that catch the anti-pattern automatically.
Practices the team continues without me.
Defaults that run on their own - teams opt out, not opt in.
People who grew through the work and own the solution.

How the work moves

Question the premise before building.
Map the whole system before choosing the fix.
Build the fix and the guardrails together.
Leave the better path easier than the old one.

I formalized this pattern as QSAIL.

Explore QSAIL

Where this work sits

  • Observability and reliability
  • Platform cost and capacity
  • Migration risk
  • Performance under growth
  • Monolith modernization
  • Developer platform and CI/CD friction
  • Regulated or audit-heavy environments
  • Enterprise multi-tenant platforms
  • From embedded devices to cloud infrastructure
C#/.NET · JS/TS · Kubernetes · Azure · Kafka · Prometheus · SQL

Engineer and founder

Engineering

20 years across enterprise SaaS, fintech, IP management, healthcare, scientific instruments, media, and regulated industries. Embedded devices to cloud platforms. I stay close to the code, the system, and the operating model.

Founder

Built and operated my own product - automotive marketplace and dealer operations platform. Full cycle: product, engineering, sales, contracts, support, P&L. Self-funded. Received an acquisition offer from a major dealer network. It proved what technical roles rarely prove: I know what technical decisions cost outside engineering.

Education

πŸ‡ΊπŸ‡Έ MIT Sloan - Management, Innovation, and Technology (2023-2025)
πŸ‡¨πŸ‡­ IMD Lausanne - Driving Strategic Innovation (2025)
MBA - Transilvania University (2009-2011)
BSc Electronics & Computer Science - Transilvania University (2004-2009)
Engineering leads - critical thinking
Product owners - done right
VPs - bigger picture ownership

If one of these problems is already expensive

I am most useful when something is already expensive - or when nobody has checked whether it is.

Either way, the first conversation is about the problem itself. The shape of the work becomes obvious after that.