About Ahsan Mahmood — how I work
Where I am, how I work, what I have shipped and what I reach for first. The long version of the biography, with the commitments I hold myself to.
- Biography
- Read the longer biography
Full-stack software developer. I build the whole product: the data model, the security rules, the interface, the Android packaging, the store submission, and the documentation somebody has to read afterwards.
- See the work
- Start a conversation
- Where I am and how I work
- Available for work
- Not taking new work right now
- Asynchronous by default
- The long-ish version
If you only read one section, read this one. Everything below it is evidence for what it claims.
What I actually do
Most of what I ship follows one pattern: a single React and TypeScript codebase that becomes a web app, an Android app and a browser extension. Not three teams and three repositories that drift — one codebase, packaged three ways with Capacitor and Manifest V3, so a fix lands everywhere at once and a feature is not silently missing on the surface nobody checked.
That is a claim about maintenance more than about speed. I still maintain products I built years ago, which is a very effective way of finding out which decisions were actually good.
Where a product needs a server it is Laravel or Cloudflare Workers. Where it needs file storage or transactional email it is FilesHub, a platform I built and operate myself. Where it needs a database it is usually Firebase or Supabase on a free tier, with the query budget treated as a real constraint rather than a formality — an unbounded list read is a bug on the first day and an outage on the day the collection grows.
A product should cost nothing to run. Free-tier infrastructure, work done in the browser wherever the browser can do it, and no paid service in the critical path. That is not frugality for its own sake — it is what makes it possible for one person to keep twenty-three things alive at the same time without a monthly bill that grows faster than the products do.
It rules things out, and I would rather say which:
No iOS. There is no Apple Developer account, so I do not ship to the App Store and do not claim to.
No feature that needs a paid API in the middle of it, unless you are paying for that API and know you are.
No architecture that only works while traffic is small — the free tier is a budget, not an excuse.
- How an engagement usually starts
With a call, before anything is quoted. I would rather tell you on that call that I am the wrong person for the work than discover it together in month two. When I am the right person, you get one accountable person — whoever wrote the security rules is also the one who answers when the store listing is rejected.
The parts that usually get skipped are the parts I care about: honest store listings, documentation somebody can follow, and links that resolve.
These are the only figures I publish. Two of them are re-probed before every deploy, because they move — and a stale number is the easiest thing on a page to disprove.
Each figure is printed beside where it came from. A number with a source is checkable, and a portfolio number nobody can check is worth less than no number at all.
Where it ships
The same codebase, packaged five ways. The counts come from the probe recorded in BIO.md and are re-verified before publish.
Web applications live today — hiring and health platforms, a laboratory information system, a link-management SaaS, exam preparation, tax compliance, a Slack archiver and several developer toolboxes. React and TypeScript throughout, deployed to Firebase Hosting or Cloudflare Pages.
Google Play listings, all packaged with Capacitor from the same web codebase rather than rewritten. That covers the parts people forget: the merged manifest audit, the Data Safety form, the ten App-content declarations, and a listing written to pass review rather than to sell.
**There is no iOS half.** I have no Apple Developer account, so nothing here has ever shipped to the App Store — and a portfolio that claims a platform it has not shipped to is the first thing a client finds out about.
Browser-extension listings across the Chrome Web Store, Firefox Add-ons and Edge Add-ons — Manifest V3, built once and submitted three times. No remote code, which is both the store rule and the reason these keep passing review.
Packages published to npm under the `aoneahsan` maintainer.
One caveat I would rather state than have found: that count is what the registry returns for the maintainer, so it includes a package scoped to a client organisation and two legacy pairs that were renamed rather than replaced.
Documentation sites, one per product that needs one. They are not an afterthought here — a package nobody can work out how to install is a package nobody uses, and the docs site is usually the thing that decides which of those it becomes.
How I work
- Scoped on a call, before it is quoted
A fixed number attached to an unscoped brief is a number one of us is going to be unhappy about. The call is free and it is where I say whether I am the right person.
- One person accountable for all of it
The person who modelled the data is the person who wrote the security rules, packaged the Android build and answered the store reviewer. Nothing is handed over a wall, so nothing falls off it.
- Run it before calling it done
A green build is not evidence that a feature works. I exercise the actual flow as a real, non-admin user — which is how the interesting failures get found, because they are invisible to every static check.
In the store listing, in the docs, and on this page. Every limitation you read here was cheaper to write down than to discover.
- Leave it maintainable by someone else
Full IP transfer, documentation that matches the code, and a handover that assumes I am not available. If the project only runs while I am on it, I have not finished.
What I reach for
Worth being explicit about
MongoDB and GraphQL. Both are real on my CV and both belong to the Perkforce years — I do not build new products on either.
I build interfaces and I care about them. Brand design and illustration are somebody else's craft.
I wire products up to models. I do not train them.
Things people ask me first
- Are you available right now?
Yes. Since March 2026 I have been independent, working on my own products full time and taking client projects alongside them. Fixed price, milestone, retainer or fractional — whichever fits the shape of the work.
- Do you work with teams, or only solo?
Both. I have led delivery for a small team as a project lead, and I have shipped entire products alone. On a team I am most useful owning a vertical slice end to end rather than a layer across everything.
- What time zone are you in?
Pakistan Standard Time, UTC+5, with no daylight saving. I work asynchronously by default and routinely schedule calls across US, UK, EU and Australian hours.
Can you take over a codebase somebody else wrote?
Yes, and it is a common engagement. It starts with an audit — code quality, security rules, performance, dependency health — and produces a prioritised roadmap before a line is changed.
No. I have no Apple Developer account, so nothing I build has gone to the App Store. Android and the web are the surfaces I can genuinely take through to release.
- Why is there no client list on this page?
Because most of it is not mine to publish. The clients that **are** public — through my CV, npm and the app stores — appear on the projects page with the work attached. An anonymous “15+ happy clients” badge proves nothing, so it is not here.
Have a look, or say hello
The projects page has everything with a link that resolves. If you would rather just describe the problem, the contact form goes straight to me and I reply within one business day.
- See the projects
- Read the longer story
- Get in touch
Full-stack developer based in Lahore, Pakistan, working with clients worldwide. One React and TypeScript codebase becomes a web app, an Android app and a browser extension.
- I ship products, not prototypes.
- Lahore, Pakistan
https://aoneahsan.com/about