Skip to content
AAMIQRAM — home
Portrait of Abu Abdullah Md Iqram

// About

Abu Abdullah Md Iqram

Frontend Developer · Chattogram, Bangladesh

I build web applications with React and Next.js, and I work on the API and data layers underneath them when a product needs those to exist. I am not trying to be a backend engineer who does some frontend — I am a frontend developer who would rather own the whole path than hand over a screen and wait.

Most of my work sits in the middle ground between a pure frontend and a pure backend: the checkout that has to survive a failed request, the inventory record that has to stay consistent, the live order status that has to update without a page refresh. That is the part of development I find most interesting, and it is what the projects in this portfolio are mostly about.

I am early in my career, and this site is written to be useful rather than impressive: every project says whether its claims were read out of source or taken from my own account of the work. What I do have is a working method, and enough projects to show it applied.

// Current focus

  • Building

    Commerce products end to end — catalogue, checkout, delivery rules, order state — with the interface as the part I care about most.

  • Learning

    The layer between the interface and the database. Almost every bug I have found there was an assumption somebody never wrote down.

  • Looking for

    Project work where I can own a feature from the schema to the screen, on a team that cares what the code will look like in a year.

How I got into this

I started a BSc in Mathematics at Chittagong College in 2023, and picked up programming alongside it out of curiosity rather than plan. I wanted to find out whether the thing I was studying could be made to do anything useful. What kept me in it was not the theory but the moment an idea stops being a screen and becomes something a person can actually use.

The mathematics turned out to be more useful than I expected. Proofs are mostly about being precise about the conditions under which a claim holds, and a large share of what presents as a frontend bug is an unchecked assumption about a shape or a boundary. That has been the most transferable thing I have picked up from the degree so far.

Education and training

Both of these are still running. This is the route in the order it happened, not a list of finished qualifications.

  1. 2023Ongoing

    BSc in Mathematics

    Chittagong College

    An undergraduate degree in mathematics, taken alongside the programming work rather than before it. Proofs, stated assumptions, and being told precisely where a claim stops being true.

  2. 2025Ongoing

    MERN Stack Web Development

    Programming Hero

    Full-stack web development coursework with a real scope per assignment: an Express and MongoDB API behind a React client, then Stripe checkout, then Firebase-backed authentication.

  3. NowCurrent

    Building whole products, not screens

    Chattogram, Bangladesh

    Working end to end: the interface, the API, the schema and the deployment. Right now that means commerce — catalogues, checkout, delivery rules, order state — and the occasional native application when I want to understand a platform other than the browser.

How I approach building applications

I start from the model rather than the screen. Working out what an order is, what a product variant is allowed to contain, and what the database should refuse to store tends to make the interface easier to build afterwards. Validation belongs at the API boundary with a schema the client and server both agree on, and pricing rules belong in pure functions that can be tested without a browser.

On the frontend I keep server state and client state separate, because conflating the two is what turns a data fetch into a rendering bug. I care about the parts users actually feel: readable type, visible focus states, layouts that hold up from a 320px phone, and pages that do not shift while data loads.

What is here, and what is not

This is a documentation-style portfolio rather than a résumé. There is no employment timeline, because I would rather not pad one out with dates I cannot stand behind. What there is instead is a directory of projects with case studies, and engineering notes on the decisions behind them.

Every project entry states how its claims were checked. Where a public repository exists I read the actual package manifest and say so; where one does not, the case study is labelled as reported rather than verified. That distinction runs through the whole directory, and it is the reason the engineering notes read the way they do.

Selected work

Three projects carry most of the weight here. Each one is written up with its architecture, its data model, and the parts that were harder than expected:

  • Unity Shop — A multi-vendor marketplace, built on Next.js with real-time order updates.
  • Your Iyanat — A jewellery storefront built for the Bangladeshi market, with checkout and after-sales workflows.
  • Local Chef Bazaar — A full-stack food marketplace connecting customers with home cooks.

What I am drawn to

Mostly the unglamorous parts. Data modelling, the boundary between a client and a server, and the accessibility work that decides whether the thing is usable by everyone. The engineering notes cover the same ground from the other direction, and the tech stack page lists every tool involved with the project each one came from.

  • Frontend — The part I specialise in. Component composition, responsive layout, and keeping data fetching out of components.
  • Backend & Real-Time — Enough backend to connect the interface to something real: REST services, authentication and a live channel where a product needs one.
  • Data & Persistence — Relational when the domain is relational, documents when it is not, and a typed access layer in both cases.
  • Authentication & Validation — Identity, permissions and input contracts, with the API as the only authority.
  • Payments & Media — Checkout flows that work with the payment methods customers in this market actually use, plus the media pipeline around them.
  • Tooling & Platforms — Version control, build tooling and where these things run.