My 20 years on the web: what changed and what stayed

It started less glamorously than a “career in tech” sounds

I have worked on the web for roughly 20 years. It began with a webmaster role at an online store, without a grand career plan and long before every professional step became part of a personal brand.

The work was concrete: adding products, organizing categories, updating content, finding bugs, and fixing things that almost always broke at the worst possible time. Sometimes the problem was design, sometimes code, and often it was simply getting the store working again as quickly as possible.

By around 2010, building websites and working on frontend had clearly become my main professional direction. A collection of practical tasks first developed into a craft, then into a career across different businesses, markets, industries, and technical environments.

Those early years shaped how I see websites more than any framework that arrived later. They taught me not to treat a site as a visual surface alone. It is a living business system connecting content, technology, users, and internal workflows.

Today my work sits at the intersection of frontend development, web design, UX, performance, accessibility, SEO, and conversion optimization. The tools are more advanced, but the core responsibility remains the same: a website has to work for the people visiting it and for the organization operating it.

I have lived through several web “revolutions”

Over two decades, the technical work has changed almost beyond recognition several times:

• static HTML and table-based layouts
• CSS layouts and more semantic markup
• browser-specific fixes and endless compatibility problems
• the jQuery era
• responsive design and mobile-first development
• WordPress across very different business environments
• component frameworks such as Vue, React, Nuxt, and Next.js
• the move from FTP uploads to Git, automated testing, and CI/CD
• modern analytics, A/B testing, and data-informed improvement
• AI entering planning, development, refactoring, and quality assurance

Almost every new wave arrived with the same promise: this will finally make building for the web simple.

It never quite did.

New tools can make particular jobs much faster and solve genuine problems. At the same time, they introduce new dependencies, new layers of complexity, and new ways to execute poor decisions more efficiently.

A modern framework does not fix confusing navigation. A page builder does not formulate a persuasive offer. An AI assistant does not automatically know which customers a business wants to attract or which compromises make sense for a particular project.

Tools amplify decisions. They do not replace judgment.

The most important questions barely changed

The technology stack changed repeatedly. The useful questions mostly stayed the same:

• What problem are we solving?
• Who are we building for?
• What must the visitor understand?
• Why should they trust us?
• Which next step should be easy to take?
• How will we know whether the website is doing its job?

Without clear answers, even a technically modern site quickly becomes an expensive placeholder.

I have seen websites with excellent Lighthouse results where the offer was difficult to understand. I have seen visually impressive pages where visitors could not work out how to get in touch. I have also seen relatively simple sites perform well because the audience, message, and next step were clear.

Performance matters. Design matters. SEO matters. None of them can rescue a website that fails to explain what the business offers and why it is relevant.

Technology should serve the project

The web industry often treats technology choices as identity statements. WordPress, Webflow, Framer, Nuxt, Next.js, and custom development become opposing camps that people feel expected to join.

After many years, I look at the decision more pragmatically.

The right technology depends on:

• who will manage the website after launch
• how frequently the content changes
• which integrations are required
• how much custom functionality the project needs
• what technical capability exists inside the organization
• what budget and level of risk are realistic
• how long the system needs to remain useful and adaptable

A technically exciting stack is not automatically the right choice. If a small team needs a developer for every text edit, the solution may have missed the actual requirement.

At the same time, a simple page builder is not always sufficient when performance, localization, complex data, or specialized user flows are central to the project.

The best technology is not the one that looks most modern in a conference presentation. It is the one that solves the real problem reliably without creating unnecessary obstacles later.

Performance, accessibility, and maintainability belong together

Performance, accessibility, and maintainability have often been treated as separate technical topics. To me, they are parts of the same quality question.

A site that loads quickly but fails for keyboard users is incomplete. A visually polished page that stutters on an average phone is not well designed in practice. A site that requires specialist knowledge for every small change creates a different kind of cost.

During one marketing-site performance project, for example, I helped move the GTmetrix result from B to A, with approximately:

• 91 Performance
• 96 Structure
• around 1.2 seconds LCP
• roughly 6 milliseconds Total Blocking Time
• CLS 0

There were no secret tricks behind those results. The work came from consistent attention to images, fonts, JavaScript, third-party scripts, and the actual loading behavior of the most important templates.

The numbers are useful because they make part of the user experience measurable. They are not the business outcome by themselves. A page can load in 1.2 seconds and still achieve nothing if it then presents a generic or confusing message.

Technical quality, clear content, accessibility, and conversion paths therefore belong in the same conversation.

From new frameworks to better outcomes

Earlier in my career, I followed new frameworks and tools very closely. That was necessary: anyone working on the web has to keep learning and adapting.

Today, I care less about whether something is new and more about whether it produces a meaningful improvement.

I am more likely to ask:

• Can a visitor understand the offer faster?
• Can they find the relevant information more easily?
• Can they take the next step without unnecessary friction?
• Does the site work on an ordinary phone and an average connection?
• Can the client’s team maintain it after launch?
• Will the technical foundation remain stable as content and functionality grow?

That may sound less exciting than the next major technology wave. For a business, it is usually more valuable.

Experiments replaced some of the opinion

Since around 2019, structured A/B testing and experimentation have been a regular part of how I approach UX and conversion work.

That also changed how I think about design. Discussions about headlines, buttons, or page structure are often conducted as if there were one objectively correct answer that an experienced person should simply recognize.

Experience helps us form better hypotheses. It does not guarantee that a change will work for real visitors.

Some experiments produce clear improvements. Many finish without an obvious winner. That is useful too: a flat result can stop a team from releasing a change only because it looked better in a meeting.

The main lesson is not that everything needs to be tested. It is that opinion and actual effect are not the same thing.

AI is a multiplier, not a shortcut

AI is the latest major change in my daily work. I use it for initial drafts, research, code scaffolding, refactoring, tests, translations, and review.

Used well, it saves a great deal of time. It can expose relationships within a large codebase, suggest alternatives, and reduce repetitive work.

It can just as quickly produce generic writing, unnecessarily complicated code, and confidently expressed mistakes.

That is why human review remains essential:

• Does the proposal solve the actual business problem?
• Is the code secure, understandable, and maintainable?
• Are the facts correct?
• Is the language specific and appropriate for the brand?
• Does the interface work outside the ideal example?
• Would I publish the result under my own name?

I treat AI as a multiplier, not a replacement for experience. It makes good work faster when someone can judge the quality. Without that judgment, it also makes bad work faster.

Different markets, familiar problems

Over the years, I have worked with businesses and teams in Serbia, Norway, Sweden, Slovenia, Croatia, and Germany.

The markets, languages, and expectations differ. The underlying problems are surprisingly similar:

• The offer is clearer to people inside the company than to an outside visitor.
• The site looks modern but is slow or difficult to use.
• Content has accumulated for years without a clear structure.
• Nobody knows exactly who owns the website after launch.
• The business is planning a complete rebuild when targeted improvements might deliver more value.

The more projects I see, the less I believe in universal solutions. Good work begins with context.

Not every problem needs a new website

People often arrive with an existing site, an idea, or a redesign proposal and are really asking the same question:

Are we trying to solve the right problem?

Sometimes the answer is that a new website makes sense.

Sometimes the immediate need is better structure, stronger service pages, clearer positioning, or fixes to mobile usability, performance, and forms.

Sometimes the best next step is not a rebuild at all, but an honest review of what already works and where attention, time, and business opportunities are actually being lost.

After roughly 20 years on the web, this may be the biggest change in how I work: I do not want to sell a predetermined solution as quickly as possible. I want to understand first which improvement genuinely makes sense for the business.

Clarity first. Tools second.

If you want to talk through your project, get in touch. I will not promise magic. I will give you direct feedback based on what I have seen work, and fail, across two decades on the web.

Want to think through your project together?

Book a short conversation about where you are stuck and what “better” should mean for your business, not only for the appearance of the homepage.