Web development 10 years ago and now: notes to my junior self

Around 2015 I used to edit websites directly on the server. Open the file in FileZilla, change a line of PHP, save, refresh the browser. A white screen meant I'd forgotten a semicolon. There were no backups. Git existed, but it was "for serious projects".

Today I run a small studio in Tashkent. Our latest big project, the website for the law firm Enlawyer, only goes to production after GitLab CI builds the image and runs the checks. Ten years sit between those two points, and I wanted to sort out which parts of that decade actually matter.

What it looked like back then

A typical project of mine in the mid-2010s: PHP, MySQL, jQuery, Bootstrap 3 and a pile of plugins downloaded from some archive site. All the styling in one 4,000-line CSS file. A contact form built on mail() that sent half the messages straight to spam.

The strange part is that it worked. Clients got their websites, the websites loaded. Every change was just a small lottery.

Tezda Sotaman: Yii2 in 2021

Tezda Sotaman is a classifieds marketplace: selling and renting homes, construction, hotels. We built it in 2021–2022 on PHP Yii2 (the advanced template, with separate frontend, backend and api apps), MySQL, and a Python Telegram bot next to it.

I'd pick a different stack today, and not because Yii2 is bad. It's predictable, its code generator is great, and the marketplace runs fine on it. The problem was elsewhere: even in 2021 it was hard to find a young developer in Tashkent who wanted to write Yii2. Everyone was learning React and Python. You choose a stack for the task, but also for the pool of people who'll be maintaining it three years later.

That's the first lesson I'd pass to my junior self: the technology you pick today becomes somebody's job later.

What really changed

Strip away the fashion and I count four big shifts.

Docker and CI took the fear out of deploys

This is the big one. A release used to be an event. On Enlawyer, a deploy now looks roughly like this:

deploy:
  stage: deploy
  script:
    - docker compose pull
    - docker compose up -d --remove-orphans
  only:
    - main

Nothing clever. But those few lines mean anyone on the team can ship a change, and the server doesn't turn into a museum of manual hotfixes.

SSR brought us back to the server, only smarter

It's a funny loop. In 2015 PHP rendered HTML on the server. Then everyone moved to SPAs, and search engines saw an empty page with <div id="app">. Then Nuxt and Next.js arrived and went back to rendering on the server, this time with components and hydration. For our clients this matters: a law firm, a TV channel or a clinic gets customers from Google, and an empty page for the crawler doesn't work for them.

Hosting and SSL

In 2015 a site lived on shared hosting with cPanel, next to a hundred other people's sites. If a neighbour got infected, everyone suffered. SSL certificates cost money, so half the sites on the Uzbek web ran on plain HTTP, and browsers didn't complain yet.

Today almost every project of ours runs on its own VPS: nginx, Docker, PostgreSQL, Redis. Let's Encrypt certificates are free and renew themselves. Monitoring sends a Telegram message if a site stops responding, and I hear about it before the client does. Sounds minor, but ten years ago I usually found out a site was down from the client, and that was a very unpleasant call.

TypeScript

I resisted for a long time. It felt like extra bureaucracy. I changed my mind on a project where the price field came from the backend sometimes as a number and sometimes as a string, and we spent two days hunting the bug. With types, the editor catches that.

AI in the editor: no fireworks yet

I'm writing this in August 2025. Everyone on the team uses AI assistants. They're good at boilerplate, migrations, tests and translating UI strings into Uzbek, Russian and English. That honestly saves us hours.

But they don't design architecture. And they confidently write code that looks right and breaks on an edge case. That's more dangerous for a junior than for a senior: a senior sees where the assistant made things up, a junior doesn't. I'd tell my younger self to learn to write code without the assistant first, and only then use it to go faster. I'll write separately later about how we use AI in the studio.

What didn't change at all

This is the interesting part. Ten years, every tool replaced, and the hard parts of a project are the same ones.

Talking to the client. Clients still come with "we need a site like theirs" and a screenshot from Instagram. The developer's job is to figure out what the business actually needs. Sometimes it's not a website at all but a Telegram bot. No framework replaces that conversation.

Deadlines. They still slip in the last 10% of the work: translations, content, "let's add just one more thing". In 2015 I thought that was inexperience. Now I know it's a property of projects, and I plan a buffer for it.

Content. You can't launch a site without text and photos, and the text almost always arrives last. Enlawyer has three languages, EN/RU/UZ, and every page exists in three versions. That's more work than the entire frontend.

Responsibility. If a client's site goes down at night, you're the one they call. Docker and CI made it rarer. They didn't make it go away.

What I'd tell my junior self

No philosophy, just a list. In 2015 I'd have printed it and pinned it above my desk.

The last one isn't technical, but I'm keeping it. For my first couple of years I charged so little for websites that it didn't even cover my time. If you're curious how pricing works for us now, our web development page has clear ranges.

One more thing. Almost every framework I learned in 2015 is irrelevant now. The ability to understand someone else's problem and carry a project all the way to launch is exactly as useful as it was then. That's where your first years should go.