Journey

Phones were charged off a solar panel. Neighbours would hand us one, I would plug it in and then spend the next hour opening every menu and changing every setting, and hours later we would find it almost exactly as flat as when it arrived. It is a funny story now. At the time it was the only access I had to a computer of any kind.

I got in front of a real one in 2012 and bought my own in 2016 — a low-powered dual-core desktop, paid for slowly. The reason it became a career rather than a hobby is unromantic: it was the one thing I owned that could plausibly change the next ten years.

An older brother pointed me at web development and told me where to start; that was most of the guidance available. Material in Bangla barely existed, my English was not strong enough to read the good English material quickly, and the community you can ask a question of today was a fraction of its current size. A problem a beginner would now solve in ten minutes could take me two or three days.

That is where the habit came from. When there is nobody to ask, you read the source, change one thing and watch what breaks — and I have used that on every unfamiliar codebase since, including every framework I have picked up as an adult.

By the end of it I could build and style a page properly, and I had enough PHP to stop treating the server as somebody else's problem. Which is what made the next step possible.

The first paid job came in June 2018, two years after I started learning. For the next two years the work was almost entirely design-to-code conversion — a PSD or a Figma file in, hand-written HTML and CSS out. Narrow work, and a good place to get fast at the part everything else sits on.

The value was volume — a compressed run of briefs, deadlines and handovers that would have taken years to accumulate through referrals. Fixed prices meant every bad estimate came out of my own evenings, which is an expensive and very fast way to learn what to ask before quoting. That discipline is still the reason I can put a date on a piece of work and hold it.

WordPress arrived at the end of 2020. With HTML, CSS, JavaScript and PHP already in place it was not a new subject, it was a new arrangement of ones I knew — and it was where the work was. Within a few months it was most of what I sold, and a few months after that it was what an agency wanted a partner for.

White-label means the work ships under the agency's name: their designer's file, their project manager, their client. Feedback arrives specific and immediate, measured against a file rather than an opinion, which is uncomfortable for about a month and then extremely useful.

The range is wider than a portfolio usually admits — marketing sites, custom themes with modelled content, page builders where the client's own team had to keep editing, LMS and education sites, WooCommerce stores, and a great deal of ordinary CMS work, often on hosting nobody involved chose.

Forty-five of anything is enough to stop guessing. The decision that mattered on each one turned out not to be technical: it was who would be maintaining this in a year. The other thing it produced was a list — the same handover questions, the same requests, the same awkward edit, repeating across unrelated clients. Written down, that stops being anecdotes and becomes a specification.

Defer Forms for Contact Form 7 came straight off the list: a visual builder for Contact Form 7, around 12,400 lines of PHP behind a React canvas, built so that no form already living on a site has to change. The others followed the same rule — take a job clients kept asking me to repeat, and make it something they can do themselves.

Building them is where the modern front-end work actually started. A drag-and-drop canvas with selection, undo and a properties panel is not a jQuery problem; it is a React application that happens to be mounted inside somebody else's admin. The PHP side stopped knowing anything about the interface and started answering REST requests instead, which is the same seam I would later build an entire API across.

The discipline that came with them was the WordPress.org review process — coding standards, escaping, internationalisation, nothing bundled that should not be. Useful to have applied to your own code rather than only to a client's.

WordPress answers most of the hard application questions before you start — users, roles, storage, routing — and it answers them one particular way. The plugins kept running into the edge of that. A permission rule about a record rather than a type of thing is not a capability; a table you actually want to query is not post meta. At some point the honest move is to build where those decisions are yours.

So the current work is Laravel and Vue: REST APIs authenticated with Sanctum, authorisation models designed rather than inherited, migrations, and single-page front ends that have to deal with loading, failure and reconciliation honestly. Decoupled on purpose — an API I could put a second client in front of, rather than one framework quietly doing both jobs.

The patterns that keep proving themselves are the ones the earlier stages taught me. Model the data before the interface. Keep the dependency count low, because every one is something somebody inherits. And decide by who maintains it, which turns out to be as true of an API contract as it ever was of a client's homepage.

Client work continues alongside, and funds the rest.