The questions worth asking before we start

Mobile apps, SaaS platforms, marketplaces, dashboards and admin tools — anything where the interface carries real weight. I work best on products with genuine complexity: multiple user types, real data, or a workflow that has to survive daily use. Brochure sites are not the best use of my time or your budget.

Both. With startups the value is usually in cutting scope to what actually needs to exist for launch. With established companies it is usually in untangling a product that grew feature by feature. Different problems, same process.

Yes — most of my work is inside a team, not around one. I join existing rituals, work in your files, follow your conventions and adapt to whatever system already exists rather than replacing it because it is not mine.

I am based in Lahore (PKT, UTC+5) and comfortably overlap with European mornings and US East Coast mornings. Most of my clients are in North America, the UK and the Gulf, and we settle a fixed daily overlap window in the kickoff.

A focused mobile app is usually 4–8 weeks end to end. A SaaS platform or multi-role product is 6–12. A UX audit is 1–2 weeks. Those ranges assume feedback comes back within two working days — review latency is the single biggest cause of slipped design timelines.

A decision-maker who can approve direction, access to two or three real users, whatever analytics and support data already exists, and one consolidated round of feedback per review. That is genuinely it — everything else I can work out as we go.

Two structured review rounds per phase, which is almost always enough when feedback is consolidated rather than arriving in fragments. If the direction changes because something new was learned, that is not a revision — that is the process working, and we re-plan together.

Some form of it, yes — even if that is five interviews and a competitive teardown inside one week. Designing without any evidence means guessing, and guessing gets expensive at the build stage rather than the design stage.

Editable Figma files you own outright: flows, wireframes, high-fidelity screens with every state, a component library with tokens, an interactive prototype, and annotated handoff documentation. Plus a recorded walkthrough for whoever joins the team later.

Every state. Empty, loading, error, offline, permission-denied, first-run and too-much-data. This is the single biggest difference between a design that ships smoothly and one that generates a hundred questions during the build.

I do not build production front-ends, but I read and write HTML and CSS well enough to know when a design is expensive to implement, to review a staging build properly, and to have a specific conversation with engineers instead of a vague one.

Yes, and I recommend it. I run a design QA pass against staging and file specific tickets with screenshots. The gap between a design file and a shipped product is where quality usually leaks out.

Fixed price per phase for defined scope, or a weekly rate for ongoing work. You get the number before anything starts, and it does not move unless the scope does — in which case we agree the change in writing first.

Yes, routinely. Quite a lot of my work is under NDA, which is why some projects appear in this portfolio by outcome rather than by screenshot. Send yours over before the first call if that is easier.

You do, on final payment. Full ownership of the source files, the components and the assets. I ask only for permission to show the work in this portfolio, and I will happily wait until after your launch, or skip it entirely.

I design full-time at SakhiSoft and take on one or two focused external engagements a quarter. The fastest way to find out is to email me — I answer every genuine enquiry within a working day, including the ones I have to decline.