I run product and engineering at Entropy Labs, and I take on a small amount of outside work next to it. It’s usually one of three shapes.

Reviews

A fixed, short look at something that already exists: an architecture that’s getting harder to change, an AI feature that demos well and wobbles in production, a backend path that’s become the bottleneck. You get a written read on where the real problem is, what to do first, and what to leave alone.

Builds

Hands-on work on the parts that are expensive to get wrong: backend services, data models that have to stay correct under concurrency, AI workflows with proper failure handling and approvals, or a product from first version to something people rely on. I write the code, and I leave it in a state your team can own.

Advice

Ongoing product and technical direction for a team that’s already shipping: which problems are product problems and which are engineering ones, what the next few decisions should be, and where AI helps versus where it adds latency and confusion.

Where I’m useful

  • The product is live, or close to it, and the stakes are real.
  • Correctness, latency or reliability matter more than another feature.
  • You want someone who can both diagnose it and fix it.

I’m probably not your person for quick marketing sites, “add AI somewhere” projects without a user problem behind them, or strategy work with no interest in implementation.

What I bring

  • 2 h to 25 min: manual onboarding flow, after the automation work at Entropy.
  • 750 to 230 ms: reporting endpoint, from reshaping the query rather than adding hardware.
  • 15+: specialist agents running in Obelisk.
  • 170 merged pull requests in open-source tools like kitty, calibre and libtorrent.
  • Entropy Labs: Ignite acceleration round winner; Financing approved under Accelerate Prosperity; Exhibited at GITEX Global 2025; Exhibited at LEAP 2026.

The details are in the case studies and the writing, and the open-source record is public if you’d like to read my code before we talk.

Starting a conversation

Email is best: hi@mhassan.dev. A few lines on what you’re building and where it hurts is plenty. If a call is easier, book 30 minutes. On the call I’ll ask enough questions to find the real pressure point and tell you honestly whether I’m the right person for it.

For roles, talks, workshops or student questions, email works too.