I build software that runs in production,
and I explain the decisions behind it.

Bank of Punjab wanted to send customers SMS alerts for balance, withdrawals, transfers and other account activity as soon as they happened. The balance in the SMS had to be correct, and we could not add load to the core banking system.

Listen to events from the IRIS transaction switch instead of polling the database. Each switch event triggers a notification. Message formatting, delivery and account routing are kept as separate parts.

Using events meant no constant database polling. Careful handling of partial, reversed and duplicate transactions lowered the chance of sending a wrong balance.

Many organizations needed to run their elections on one platform: onboarding, voter records, election setup and results. Each organization's data had to stay separate from the others.

Used .NET 6 with Clean Architecture and DDD. Election rules live in the domain layer and do not depend on the UI or the database. Tenant separation is enforced in the domain layer, not only in queries.

Each tenant can be customized without copying code. Adding a new organization became a configuration task, not a development task. Domain tests run without any infrastructure.

Three smart-city platforms needed REST backends. Each one needed clear domain boundaries, high availability and the ability to grow on its own. The deadlines were tight.

Built modular .NET Core services on top of a shared core. Each platform owns its own domain, but they share common code for login, logging and database access instead of writing it three times.

Shared login, logging and data-access code meant less duplicate work, while each platform still kept its own clear boundaries.

A grocery business in Cyprus needed a customer app and a CRM for orders, stock and payments. When something failed, the system had to show it clearly.

Built the front end with TypeScript and React on top of a safe payment integration. Orders are idempotent, failures have their own clear states, and payment reconciliation was built in from the start.

Idempotent orders, clear failure states and reconciliation made payments easier to run and debug, and stopped duplicate orders.

A coding agent in the terminal needs to read code, edit files and run shell commands. If the server runs these tools, every user's private code and shell access go through a third party, which most teams will not accept. Also, a "plan mode" that only relies on prompt instructions is not safe, because the model can ignore it.

The server only defines the tool schemas and has no tool code. The CLI runs the tools locally, limited to the project folder, and keeps the agent loop going on its own. Plan mode gives the model only read-only tools. Build mode adds write and shell tools. This is enforced by the tool list, not by the prompt.

Code and shell access stay on the user's machine. In Plan mode the model cannot edit files because there is no write tool to call. Billing is based on tokens, uses idempotent usage events, and checks the user's balance before calling the model.