Why do web developers take so long?

So, you have a seemingly simple task and you phone your web agency, who suck air through their teeth and say it isn't as simple as you think. You can visualise dollar symbols scrolling through their eyes like a cartoon character.

But why?

Not every web developer does this, and that's actually part of the problem!

First, a caveat: not all developers pause to think it through. Some dive straight in, make changes without fully understanding the system, and leave a trail of destruction behind them. The ones who take their time aren't being precious, they're being methodical, and are usually more efficient in the long term.

We have been asked by other agencies, who white-label our services, to go in to a live system and blindly make changes hoping they’ll work. Errrrr, no, that’s not how we work, read on to find out why.

Responsibility doesn't end when the work does

When a developer makes a change, they own the consequences. If something breaks it's on them to fix it, and looks really bad for the agency. That awareness changes how we approach every task. Every line of code touched is a commitment, so good developers make sure they understand what they're touching before they touch it.

Backups and testing aren't optional extras

Before anything changes, a safe restore point needs to exist. After the change, it needs to be tested. Not just "does it look right" but functional testing, edge cases, different browsers, different devices, and different user roles. Skipping this isn't faster; it just moves the cost to a more inconvenient moment. Our task is to try and break things, so that users don’t.

Version control keeps everything in sync

On any project involving more than one person, and often solo, code lives in a version control system. Changes need to be branched, reviewed, and merged carefully. A poorly managed update can overwrite someone else's work, introduce conflicts, or push untested code to a live environment.

Environments and deployment pipelines

Development shouldn’t happen directly on the live website, especially with large or complex builds. Changes are built locally, tested on a staging environment that mirrors the live one, and only then deployed. Each step requires careful handling, and database differences, environment specific configuration, and deployment processes all need to be managed correctly. Pushing straight to live is a risky move, and certainly not a time saver, and clients who've experienced an agency do this will know why!

The goalposts may have moved since last time

Websites and web applications aren't static. Even if a developer worked on the same system six months ago, the codebase may have been updated, third party integrations may have changed, and the database schema may look nothing like it did before. Before writing a single line, there's often a familiarisation process, understanding the current state of the system, not the remembered one.

What the customer describes isn't always the actual problem

This is my personal favourite! A client reports that "the form suddenly stopped working." Yes, the form suddenly could have stopped working, but it could also translate to the form never worked, the client’s emails are broken in general, the client has a newer member of staff who doesn’t understand where emails are routed, their IT company have added a firewall that blocks enquiries, the enquiry has been deleted accidentally, or there is no issue as the end user insists they completed the form when they didn’t. Developers can't take the reported symptom at face value.

The codebase may carry years of accumulated decisions

Websites that have existed for a while, particularly those that have passed through multiple agencies or developers, often carry layers of amendments built on top of other amendments. Code written under one set of assumptions gets patched by someone who didn't fully understand it, then patched again by someone else. Untangling what a system is actually doing, versus what it was originally intended to do, can take significant time before any new work can be done safely.

Third party plugins and services have a habit of changing

A plugin that behaved one way a year ago may have updated its API, deprecated a feature, or introduced a conflict with another part of the stack. External payment gateways, booking systems, CRM integrations, and mapping tools all evolve independently of the website they're embedded in. Any task that touches an integration requires checking that the integration still works the way the code expects it to.

Infrastructure and platform changes create hidden dependencies

Page builders, template frameworks, CMS modules, and server environments all change over time. A task that should be straightforward can become complex when a theme has been updated, a module has been deprecated, or a hosting environment has moved to a new PHP version. These changes don't announce themselves; they surface when something breaks.

Seemingly unrelated things are often very related

Renaming a page sounds trivial. It isn't always. URLs are referenced in internal links, navigation menus, sitemaps, external backlinks, Google's index, and potentially hardcoded in other parts of the codebase. A web developer who cares about the outcome thinks about all of those things before making the change. The same logic applies to altering a database field, changing a user role, or modifying a shared component, the ripple effects matter.

Performance impact

A change that works perfectly in functional terms can still quietly make things worse. Page load speed, Core Web Vitals scores, server resource usage, and database query efficiency can all be affected by changes that look innocuous on the surface. On high traffic systems especially, a developer who isn't thinking about performance is only solving half the problem.

Security implications sit behind almost every change

Any modification to a form, a user facing input, or a data handling process carries security implications. Developers who are doing their job properly are thinking about injection risks, authentication logic, exposed endpoints, and data validation. They don’t do this because they're being paranoid, but because the cost of getting it wrong falls on the client, their users, and sometimes the developer themselves.

Communication, approvals, and access

For anything non trivial, work often can't begin until scope has been confirmed, budget authorised, sign off obtained, or access granted. And access is its own problem; credentials to servers, CMS backends, third party platforms, DNS settings, and API dashboards are routinely out of date, shared with people who have since left, or simply unknown to the current client contact. Tracking down the right login, requesting a password reset through the right channel, or waiting on a two-factor authentication code from someone in another department can add hours before a single line of code is written. None of this shows up in the finished work, but all of it costs time.

The "while we're in here" problem

When a developer opens up part of a system to make a change, they often find something else nearby that isn't right such as a related bug, a deprecated function, a security gap, or a configuration that's one update away from breaking. Deciding whether to fix it immediately, flag it to the client, or carefully leave it alone, is a judgement call. Any of those options takes time, and ignoring it entirely isn't always responsible.

"Now I can see it, can you just..."

A very common source of extended timelines is the feedback loop that only starts once the client can see something live or on staging. The brief made sense originally, the work was completed to specification, and then the response arrives: "Ah, now I can see it, could we move that slightly to the left, and actually can we change the wording, and while you're there..." Each individual request might be small, but every round trip involves picking the task back up, making the change, testing it, redeploying, and waiting for the next response. This isn't a criticism of clients as visualising changes in the abstract is genuinely difficult, but it is something both sides should factor into expectations and estimates. A client, who shall remain nameless, springs to mind!

Cognitive load and context switching

Much to their disappointment, developers rarely work on a single project from start to finish without interruption. A task picked up after a few weeks, months or even years, requires re-reading previous work, re-understanding the system's quirks, and rebuilding the mental model of where things were left. This re-familiarisation cost is invisible to the client but very real in practice. It is especially prominent in smaller tasks that are easier forgotten.

The admin burden on small tasks

Small changes carry a disproportionate amount of overhead. A ten-minute code change still requires a phone call or email to take the brief, time to understand what's actually being asked, raising a job in the project management system, a developer picking it up and getting up to speed, doing the work, testing it, deploying it, communicating completion, and potentially invoicing for it. Staff time costs money from the moment the phone rings. For a genuinely small task, the surrounding admin can easily outweigh the technical work itself. This is why batching small requests together is nearly always more economical.

The takeaway

A developer who pauses, asks questions, and takes longer than you expected isn't running up your bill for the sake of it. They're being methodical. They're thinking about consequences you haven't considered yet, protecting you from problems you'll never know were avoided, and building on a foundation they actually understand.

The ones who quote fast and start immediately aren't always the better option. Sometimes they're just the ones who haven't thought it through yet, and it is likely to come back to haunt you.

If a developer offered you two options; ‘quickly’ or ‘properly’, but was upfront that "quickly" meant no testing, no backups, no consideration of wider implications, and a real risk of the whole site going down, which would you choose?

Nobody picks quickly when it's explained that way. But that's often what's being chosen when the decision is made on price or turnaround time alone.

My late father always said to me "Aaron, do it properly, do it once", and contrary to what a ‘wise’ teenage Aaron thought, he was correct.

We are Webbed Feet, we do things properly.