Skip to content
▓ welcome.txt

Solutions engineer.
Whatever it is. I get it done.

Web apps, APIs, AI systems, LLM evaluation. No handoffs, no excuses — one person who owns the outcome. 34 free tools installed on this machine as proof.

▶ Start a projectOpen toolbox…
📬 You've got mail! — build_report.msg

“Rebuilt with zero animation libraries, server-rendered chrome, and hover-prerendered navigation. Weeks, not months.”

— HasnainOS build log

Reply: hire him
▓ hasnain.bmp
Hasnain Mubashir

chess nerd ♟ · roboticist 🤖

▓ stats.log

tools
34
uploads
0
reply
<24h

📁 services/ — what I do

📁 ui_dev/

Websites & UI

Accessible React and Next.js front ends that stay fast after launch, not just on the day they ship. Server-rendered where it matters, client-side only where it earns its place. Real keyboard and screen-reader support, because an interface nobody can operate is not finished. Performance budgets enforced in CI so a regression fails the build instead of quietly costing you traffic for a quarter. CWV green.
📁 ai_llm/

LLM training & evaluation

Rubric design and scoring, red-teaming, prompt and response evaluation, and the edge-case hunting that finds the failure your demo never does. Multi-turn review where the second turn is where things actually break. The output is not a vibe check — it is a graded rubric you can argue with, a list of reproducible failures, and a view on whether the model is ready to put in front of people. Models that behave.
📁 api/

Backend & APIs

Typed Node against Postgres and Redis, with the boring parts done properly: migrations that roll back, errors that say what went wrong, and logs you can actually search at 3am. Designed so the failure modes are known before launch rather than discovered by your users. Honest about what needs a queue and what does not. Launch-proof.
📁 perf/

CWV audits

Measurement first, then fixes, then a budget so it stays fixed. LCP, INP and CLS traced to the specific element, request or font that causes them — not a generic list of recommendations. You get the numbers before and after, the reasoning in between, and the CI check that stops the next deploy undoing it. Speed sticks.
▓ how_i_work.txt — four rules

How I work

One person owns the outcome, which only works if the way of working is predictable. These four hold on every project, whether it is a landing page or an evaluation harness.

  1. Scope it honestly

    Before anything is built, we agree what done looks like and what is out of scope. If I think the thing you asked for is the wrong thing, I will say so once, with reasons, and then build what you decide.

  2. Ship in slices

    Something real and reviewable in week one, not a month of silence followed by a reveal. You see progress while it is still cheap to change direction.

  3. Measure, do not assume

    Performance and quality claims come with numbers attached, before and after. Where I cannot measure something, I say that instead of guessing.

  4. Hand over cleanly

    Code your team can read, decisions written down where they will be found, and no dependency on me afterwards. One person owning the outcome should not become one person holding it hostage.

▓ toolbox/ — 34 items · click to run

Featured tools

image-resize png-to-svg qr-codes prayer-times palette pomodoro+28 more →
▓ blog.txt — latest_posts

Latest posts

▓ new_project.exe — tell me what you are building

Start a project

or email talktome@hasnainmubashir.com