Founder, M/AFZAL

I design what I build, and build what I design.

Most brands hire a strategist, a designer, and an engineer, then pay for everything lost between them. I am all three, so nothing gets lost. Not a moodboard. Not a deck. The thing itself, live, and findable by search and AI.

Range
Strategy, design, engineering
Based
Remote, worldwide
Status
Accepting new engagements
Start a conversation Read the story
Muhammad Afzal, lit cobalt on one side and scarlet on the other, looking up and away from the camera.

Why I work the seams, not a lane.

  1. 01Breakpoint

    I started M/AFZAL because most identities break the moment they meet a real product roadmap.

  2. 02Range

    Brands break at the seams: between the strategy deck and the design file, the design file and the codebase, the codebase and the way search engines read it. So I learned both sides of every seam. Brand strategy and identity, design systems, frontend and mobile engineering, security, and now how AI answer engines understand a brand. Not to collect titles. Every handoff I learned to remove was a place the brand stopped leaking.

  3. 03Accountability

    When one person holds every discipline, there is no one else to blame, and that is the point. Every engagement gets direct attention from thinking through launch, and every system I hand off is built to keep working after I’m gone. That’s the job: not to be present forever, but to make my presence unnecessary.

Every identity gets tested about six months in.

Two brands, one launch date, the same ambition. What separates them is whether anything was holding the thing together underneath.

  1. With a system underneath
  2. Month 1A new surface ships knowing how to behave.
  3. Month 6Someone else builds a page. It still sounds like you.
  4. Year 2The system has outlived the brief that created it.
  5. Still itself.
  1. Without one
  2. Month 1The first exception is approved, just this once.
  3. Month 6A second blue appears. Nobody remembers choosing it.
  4. Year 2The real brand lives in a folder no one can find.
  5. Rebuilt from scratch.
Close crop of the portrait: a dark t-shirt printed with the words Focus, Build, Elevate.
Detail from the portrait above. Not a slogan, a shirt.

Focus. Build. Elevate.

Three words I wear more literally than most people know. They are what keep range from turning into noise.

  1. 01

    Focus

    Range is only useful when it points at one problem. One problem worth solving this quarter beats ten half-finished ones, so I say no early and the yes means something.

  2. 02

    Build

    Every discipline I claim, I practice in production. Working software and shipped systems, not decks about them. If it isn’t real yet, it isn’t done.

  3. 03

    Elevate

    Leave every system a little more legible than I found it, including the ones I built myself last year.

From interface to infrastructure.

Each role added a discipline instead of replacing one: first the surface, then the system beneath it, then the security, infrastructure, and people that keep it alive.

  1. Ilsa Interactive

    Frontend Developer

    Dashboards, DOM performance, reusable Web Components, and responsive systems.

  2. Nextbridge

    Senior Frontend Engineer

    Design systems, performance architecture, secure token flows, technical decisions, and mentorship.

  3. M/AFZAL

    Founder & Creative Lead

    One connected practice spanning strategy, identity, systems, software, and delivery.

Range, with receipts.

Polymath is an easy word to claim and a hard one to prove. So here is each discipline, the evidence behind it, and where it happened, wherever that can be shared.

  1. 3live brand systems, strategy to launch

    Brand strategy & identity

    Identity that survives contact with the product.

    Pommel & Cantle, Firmware Lab, and ConceptKube: positioning, identity, and the production website for each, designed and built by the same hands.

    See the annotated case studies

    M/AFZAL

  2. 40%faster application loads

    Performance engineering

    Speed came from architecture, not polish.

    Lazy loading, code splitting, and granular React Query state design reduced application load times by 40% across production interfaces.

    Open the full case

    Nextbridge

  3. 70%fewer email rendering issues

    Email systems

    Reliability came from one responsive system.

    A reusable mobile-first email template architecture reduced client-specific rendering issues by 70%, replacing one-off fixes with repeatable constraints.

    Ilsa Interactive

  4. 3production frameworks

    Cross-platform architecture

    Patterns survived a change of framework.

    Reusable interface and state patterns were carried across React, React Native, and Vue, reducing reinvention between platforms.

    Production UI

  5. 4engineers mentored

    Engineering leadership

    Systems scale when understanding does.

    Four junior engineers were mentored in component architecture, token flows, debugging practice, and the reasoning behind resilient frontend systems.

    Engineering leadership

  6. 4machine-readable layers on this site

    Search & AI visibility

    Built to be read by the engines people now ask.

    Server-rendered HTML, structured data, answer-shaped FAQ markup, and explicit access for AI crawlers, so search engines and answer engines can find, understand, and cite the work.

    How this works

    This site

Also practiced in production: mobile security, authentication, observability, localization, and LLM-assisted engineering workflows. The specifics stay with the teams they were built for.

Nextbridge, application performance

Speed was an architecture problem before it was a polish problem.

Production interfaces had accumulated eager bundles, broad state updates, and uneven loading behavior. The brief was not “make it feel faster.” It was to change what the application asked the browser to do.

  1. 01 DiagnoseTrace the cost

    Separate network, bundle, rendering, and state-update costs before choosing a fix.

  2. 02 DecideLoad by intent

    Introduce route-level code splitting, lazy boundaries, and granular React Query state ownership.

  3. 03 Trade offMore boundaries, less waste

    Accept additional architectural seams in exchange for smaller initial work and clearer data responsibility.

  4. 04 Measure40% faster

    Application load time reduced across production interfaces.

Something worth building properly?

Let’s talk about what you’re building.

Six useful answers replace a blank email. I read every brief myself and reply with fit, questions, or a clear next step.

01What are you building?
02Current stage
03When must it move?

Your brief goes directly to me. Prefer email? Write directly.