Skip to content
Wiel Zouantcha

Wiel Zouantcha

Get to know me

I learned software by building my way into real problems.

I’m Wiel Zouantcha, a full stack design engineer based in Washington, DC.

I did not follow a conventional computer-science path. I studied pre-nursing, stepped away, and eventually completed a full-stack software engineering program at Flatiron School. My first production role was at SaaS Alerts, where I learned that integration work is rarely about connecting two clean APIs. It is about inconsistent data, incomplete documentation, operational constraints, and making careful claims about what the system actually knows.

I later spent three and a half years at Ethos. I joined through blockchain work and grew into a senior full-stack role spanning commerce, product interfaces, internal APIs, multi-tenant systems, and production reliability.

Alongside that work, I kept building products of my own. MTL Archives began with a public dataset and became a cultural archive. Port Observatory MTL started as a live view of the Port of Montreal. That work became PortMind, an ongoing research project: a benchmark for port-operations AI on this dataset. Diane Party Rentals put me inside the operational reality of a physical business rather than outside it writing software requirements.

I don’t always start with a product in mind. Sometimes I’m just curious about a city, a photograph, or how someone runs their business. Building gives me a way to stay with that curiosity. I can follow it from a question into the data, the interface, and eventually a conversation with someone using what I made.

How I work

Start with the operation

I want to understand how the work happens before deciding what the interface should be.

Make uncertainty visible

Missing data, model disagreement, and ambiguous rules should show up in the product. Do not hide them behind confident UI.

Build across boundaries

I am comfortable moving between product conversations, frontend interfaces, APIs, data models, tests, and deployment.

Treat reliability as product work

Health checks, permissions, audit trails, and failure behavior affect whether users trust the system.

Use AI as leverage, not evidence

Faster implementation is useful; evaluation and judgment still determine whether the result is good.

Outside the work

I’m a father, an avid reader, and someone who spends a lot of time thinking about cities, history, business, and how technology changes what small teams can build. When I’m not working, I’m usually training, reading, traveling, or somewhere inside an archive of old Montreal photographs.