A technology professional who builds to understand.

The short version

I'm Mohannad Bakkar, a technology professional based in Ontario, Canada. My work sits between a business requirement and a working system: understanding what a client needs, working out how the software and integrations should be shaped, and staying involved until it runs reliably in production.

Most of my career has been in software people depend on but rarely think about — utility billing and customer systems, and now payment and billing platforms at Paymentus. That context teaches a particular kind of patience. The software has to be correct, the edge cases are financial or operational, and the people using it have a job to do.

What the work actually involves

Technical implementation sounds like one job. In practice it is a collection of smaller ones, and the unglamorous parts are usually what decide whether a delivery succeeds:

• Reading a requirement and noticing what it leaves ambiguous.
• Designing how data moves between systems that were built separately.
• Configuring an application to match a client's actual process.
• Working through authentication, access, and identity.
• Testing the paths nobody thinks about until they fail in production.
• Launching, then staying close while things settle.

None of that is glamorous. All of it is what makes a system usable after the project team has moved on.

How I got here

My professional path has run through utility software and, more recently, fintech. At Advanced Utility Systems I worked as a technical consultant and later led the technical services team. At Paymentus, I work on payment and billing implementations across clients.

It has not been a straight line through one specialty. The constant has been systems: understanding how the pieces connect, and being the person who can trace a problem from a symptom back to its cause.

Why I build outside of work

The day job has a boundary: a client, a scope, a release. Independent projects remove that boundary and expose everything else — product decisions, design, deployment, support, and whether anyone actually wants the thing.

Basket exists because a household problem kept showing up. The home lab exists because reading about networking only gets you so far. The olive farm project exists because software meeting water, power, and distance is a genuinely different kind of engineering.

Those projects are also where I keep learning. Almost everything I know about containers, DNS, and local models came from breaking something at home and having to fix it.

What I care about in a solution

I care about how a system behaves when it is under-maintained, under-monitored, and used by someone who was never trained on it. That is usually the real test — not the demo, and not the happy path.

A solution a team can operate, debug, and extend is usually worth more than an elegant one nobody can maintain.

That belief shapes the way I scope work, document decisions, and choose between a clever design and a boring one that survives.