Hi, I'm Muhammad Umar.

I spent years as an engineer on production systems, the kind with real users and real consequences when they break. At some point I stopped wanting a bigger team around me and started wanting a shorter distance between the problem and the person solving it. So I run Syntax Planet by myself.

Most of the work is AI features, internal tools, and automation for B2B teams in Europe. The good version of that job is unglamorous. Understand the workflow properly, cut the scope to what earns its keep, ship it in weeks, then keep it boring and reliable.

Why the writing is the main thing here

Anyone can tell you they are senior. You have no way to check it, which is why every page like this one says the same thing and none of it means anything by the time you have read three of them.

So instead of describing how I think, I publish it. There are 20 pieces here, 10 of them long enough to take one thing apart properly: why an index gets ignored, why a retry can bring down a system that was fine a minute earlier, why one tenth cannot be written exactly in binary. Every claim in them is either sourced or something I ran into myself, and each piece says which of the two it is.

Read one and you will know more about whether you want me on your problem than any list of years and technologies could tell you.

How I work

These are commitments rather than values, which means you can notice me breaking them.

• Scope in writing before anything starts, including what it will not do.
• A written update every week, in three lines, whether or not there is news.
• You hear about a problem when I find it, not when the deadline arrives.
• A change to scope gets a change to the date, said out loud at the time.
• If it is not a fit, I say so and point you at what I would use instead.

What I build with, and why it matters less than you think

TypeScript, Next.js, Node, Postgres, and whatever deploys on a push. Not because they win benchmarks, but because I can move in them without thinking, and every hour not spent learning a new tool is an hour spent on the actual problem.

Almost no project fails on the stack. They fail because nobody could say in one sentence what the thing was for, or because a decision sat waiting on a person who was in meetings until Thursday. I wrote about that in your stack is not the bottleneck.