About /

CTO at Tenix. I build technology for electric fleets — where software, operations, vehicles, chargers, energy, and business reality all meet.

My work is split between two worlds that have to understand each other: software engineering and fleet electrification.

On one side, I care about architecture, platforms, reliability, APIs, infrastructure, teams, and technical decisions that scale. On the other, I care about depots, charging windows, power limits, vehicle readiness, energy cost, customer operations, and the commercial reality of moving fleets from diesel to electric.

The useful work happens in the middle.


What I do

Technology / CTO
  • Build scalable software platforms
  • Shape architecture and technical direction
  • Lead engineering teams and technical decisions
  • Keep systems reliable, observable, and supportable
  • Balance speed, complexity, cost, and maintainability
Electrification / EV business
  • Help fleets transition from diesel to electric
  • Understand depot charging as an operational problem
  • Connect charging, vehicles, schedules, and energy
  • Turn smart charging into real business value
  • Focus on uptime, readiness, cost, and operational trust

Good technology should not just work in a demo. It should help the business sell, deliver, support, and grow.


The problem I’m solving

Electrification is not only about buying electric vehicles.

For a fleet operator, the hard part starts after the vehicles arrive. Buses return late. Routes change. Chargers behave differently. Power capacity is limited. Energy prices move. Drivers and dispatchers need simple answers. Management needs predictable operations. Customers still expect transport to run.

That is where software becomes business-critical.

At Tenix, we build systems that help operators charge vehicles safely, use available power intelligently, plan around operational constraints, and understand what is happening across depots, chargers, and vehicles.

The hard part is not only smart charging. It is making electrification operationally dependable.


Technology that supports the business

I do not believe in architecture for architecture’s sake. A technical decision should help the company do at least one of these things:

Business needTechnology response
Serve customers betterReliable systems, clear UX, good integrations
Scale deliveryReusable platform, fewer one-off solutions
Reduce support costObservability, predictable behavior, simpler operations
Move fasterClear architecture, good APIs, fewer hidden dependencies
Sell with confidenceProduct capabilities that are understandable and defensible
Protect marginAvoiding complexity that becomes expensive later

Sometimes the right decision is to build a sophisticated system. Sometimes it is to delete code. Sometimes it is to say no. The job is knowing the difference.


15 years in, what I’ve learned

I started as a developer, moved through software architecture, and now work as CTO. Over time, the questions changed from “how do we build this?” to: should we build this, what will it unlock, who will maintain it, and what happens when it breaks?

I still read code because code tells the truth. So do incidents, customer calls, support tickets, sales feedback, and operational data.

The technologies that shaped me — Akka/Pekko, Kafka, distributed systems, cloud infrastructure, IoT, and event-driven architecture — taught me both ambition and restraint. Powerful systems are useful only when the organization can understand, operate, and evolve them.

Technical debt, unclear ownership, missing metrics, and over-clever abstractions all become business problems eventually.


Electrification, grounded

Fleet electrification is not a slide about sustainability. It is daily operations under new constraints.

The vehicle has to be ready. The charger has to respond. The depot cannot exceed its power limit. The operator needs to know whether tomorrow morning is safe. The business needs electrification to reduce risk, not add another layer of uncertainty.

Smart charging is not only an algorithm. It is a business tool:

OutcomeWhy it matters
Avoid peak load problemsProtect infrastructure and reduce cost
Ensure vehicle readinessKeep transport operations running
Use energy smarterImprove margins and predictability
Reduce manual workLet operators focus on exceptions, not babysitting chargers
Support growthAdd vehicles and depots without reinventing operations

Stack

Languages
Java Scala Kotlin Groovy Go JavaScript C#
Architecture
Akka/Pekko Kafka event-driven DDD distributed systems APIs
Cloud & infra
Kubernetes Docker Azure AWS PostgreSQL MongoDB
Fleet & charging
OCPP CSMS smart charging EV telemetry depot operations

Stay in contact

I like conversations with people building, operating, or buying technology in the real world — especially around software architecture, engineering leadership, fleet electrification, EV charging, IoT, and smart energy.

Reach out if you want to exchange ideas, challenge assumptions, talk about depot charging, or compare notes on how technology decisions become business outcomes.

Find me on LinkedIn or GitHub. I write when I have something useful to say — not because the content calendar says so.