# Eleven Years of Building for the Web: What Changed and What Did Not > Eleven years from hand-coded client themes to products running on 200,000 sites, and the three lessons that survived every shift along the way. **Author:** MD Jamil Uddin **Published:** 2026-08-14 **Tags:** WordPress, AI, Career **Canonical:** https://jamiluddin.com/blog/eleven-years-of-building-for-the-web/ --- The first WordPress theme I built, I wrote by hand, one file at a time. That was eleven years ago. Since then I have shipped more than fifty client websites, moved into product engineering, and spent the last few years putting AI features into systems people actually depend on. Along the way I led development on a product that runs on more than 200,000 active installations. The work looks nothing like it did in 2015. The lessons that mattered have barely moved. ## Where it started My first years were client work. Custom themes, custom plugins, WooCommerce stores, and a long list of industries I knew nothing about until the project started. Fifty or so sites teaches you a specific kind of discipline. Every project has a real person on the other end who will notice if the thing breaks. You learn to ask what a client actually means, not what they said. You learn that the last ten percent of a project is where trust is won or lost. You also learn how much of the job is not code. ## What changed when I moved to products Client work has a natural boundary. You build the thing, you hand it over, and the scope closes. Product work does not close. When I moved to Startise and started leading development on Essential Blocks, the question changed shape entirely. It was no longer "does this work for this client". It became "does this work for everyone I will never speak to". That difference is larger than it sounds: - **You cannot ask the user what they meant.** You have to design for the interpretation you did not think of. - **Every decision compounds.** A shortcut taken in one release becomes a constraint in the next twenty. - **Backwards compatibility is a feature.** Breaking someone's site to make your own code cleaner is not a trade you get to make. ## What AI changed, and what it did not The most recent shift has been AI. [Building the chatbot for BetterDocs](/blog/building-production-ai-into-wordpress/) meant embeddings, semantic retrieval, prompt grounding, and a background pipeline that keeps the index in sync as documentation changes. The model call turned out to be the small part. Almost all of the engineering was work I had been doing for years, wearing different clothes. Data quality. Job queues that survive failure. Reconciling state so the system does not quietly drift out of sync. AI did not replace the systems work. It raised the cost of skipping it. ## Three things that did not change ### 1. The unglamorous work is the product In client work it was the edge cases and the handover. In product work it is migrations and backwards compatibility. In AI work it is the sync pipeline, not the model call. The demo is never the hard part. The hard part is everything that has to keep working when nobody is watching. ### 2. Scale changes what a mistake costs, not what a mistake is A bug on one client site is a phone call and an afternoon. The same bug across 200,000 installations is not recoverable in the same way. You cannot un-ship it. That is the entire reason release process, staged rollouts and careful versioning are worth what they cost. The mistake did not get more complicated. The blast radius did. ### 3. Reducing friction beats going faster This is the one I keep relearning. The tools that made the biggest difference were never the ones that helped me type quicker. They were the ones that removed a step: [a workflow that turns a rough idea into structured tasks](/blog/how-i-turn-random-ideas-into-actionable-tasks-with-ai/), a release process that does not depend on remembering nine things in order, a site I can edit without fighting the build. Speed is a side effect. Friction is the thing worth attacking directly. ## Final thoughts Eleven years in, the through line is not a language or a framework. Both have changed more than once, and both will change again. What survived is smaller and more boring than that. Build for the person who cannot ask you a question. Respect what a mistake costs at your scale. Remove friction rather than chase speed. That is roughly what I plan to write about here: AI product engineering, WordPress at scale, and the craft that sits in between.