Every project starts with the same question.
Clients say it on the first call: "why is it broken?" Developers mutter it at 2 a.m. staring at a stack trace. It's the same question from both sides of the screen, and answering it properly — the actual why, not the symptom — is most of the job. So it became the name.
And when nothing's broken yet? The question still works. Asking "why would this break?" before writing a line of code is how you build things that don't.
Mohsin Ali
Building software since 2018 — websites, web apps, mobile apps, and the servers behind them. Most recently the client-facing engineer on BASF projects: the single point of contact for technical decisions, delivery, and the awkward questions in between, on systems that are live and in daily use.
whyisitbroken.dev is the independent practice built on that. One person who writes the backend, the frontend, and the invoice — and answers the email when something needs attention.
Everything in writing: the scope, the price, the delivery confirmation, the receipt. Not because of distrust — because six months later nobody remembers what was agreed on a call, and the person who wrote it down wins.
Plain language over jargon, one accountable person over an agency org chart, and a 30-day free window after every delivery. If it breaks in the first month, that's on me, not on your budget.