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.
Good technology should not just work in a demo. It should help the business sell, deliver, support, and grow.
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.
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 need | Technology response |
|---|---|
| Serve customers better | Reliable systems, clear UX, good integrations |
| Scale delivery | Reusable platform, fewer one-off solutions |
| Reduce support cost | Observability, predictable behavior, simpler operations |
| Move faster | Clear architecture, good APIs, fewer hidden dependencies |
| Sell with confidence | Product capabilities that are understandable and defensible |
| Protect margin | Avoiding 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.
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.
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:
| Outcome | Why it matters |
|---|---|
| Avoid peak load problems | Protect infrastructure and reduce cost |
| Ensure vehicle readiness | Keep transport operations running |
| Use energy smarter | Improve margins and predictability |
| Reduce manual work | Let operators focus on exceptions, not babysitting chargers |
| Support growth | Add vehicles and depots without reinventing operations |
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.