When is an hour not an hour?

An hour seems like the most straightforward unit imaginable. Sixty minutes. A neat block of time that can be scheduled, estimated, and costed.

Yet in web development, an hour rarely arrives on its own.

Digital work is rarely simple

The hour that appears on a project plan or invoice often rests on layers of work that never make themselves visible. Thinking, investigation, testing, and judgement accumulate quietly around the visible task. What looks like a simple block of time is usually the visible expression of something much larger.

A single adjustment may affect accessibility, content structures, integrations, security, performance, and how the system will be maintained months or years later. Digital systems are rarely machines where one part can be altered without touching the rest.

Most of the work happens before and after the code

Developers often spend a relatively short period actually writing code. The larger portion of the work tends to happen around that moment — understanding the context of a request, tracing where information enters and leaves the system, considering how something will behave across different devices and assistive technologies, and anticipating how the system might evolve in future.

This is the quiet labour of making something robust rather than merely functional.

Invisible work is a sign things are going well

Much of this effort is invisible precisely because it succeeds. When accessibility has been carefully considered, people using screen readers encounter no barriers. When performance has been managed well, pages load smoothly on slow mobile connections. When security has been properly addressed, sensitive data stays protected.

The absence of problems is the sign that considerable thought has already taken place.

Experience changes what an hour contains

A developer who has spent years building digital systems carries a large mental map of possible pitfalls. They recognise patterns, recall previous failures, and anticipate issues that might otherwise emerge only after launch.

What one person might spend a day puzzling through, another may resolve in an hour — not because the work is trivial, but because the knowledge already exists. That hour contains thousands of hours that came before it.

So what does a "day" actually include?

When charities ask about day rates, it's a sensible question. Budgets matter, and clarity helps everyone plan.

A typical development day isn't a single person at a keyboard for eight hours. It includes a developer implementing the work, a second developer reviewing the code, and project management oversight to keep everything moving. It includes testing, QA in both the code and the deployed environment, and a handover that allows a charity partner to review the changes properly.

And crucially — the "day" rarely behaves like a calendar day. Core development might happen on a Tuesday morning. Code review follows that afternoon. Testing happens Wednesday once the change is on a staging environment. Senior oversight comes before deployment later in the week. All of that gets grouped into a single development day, but in practice it unfolds across several days as the work moves through the team.

A small change is rarely just one person's work

A simple post-launch support request — updating content structures, fixing a few related issues — might involve four hours of core implementation. Around that sits code review, QA, coordination, handover documentation, and senior oversight before deployment.

What appears to be a small change quietly involves several people ensuring the work is safe, tested, and maintainable.

This is why we price in days, not in complexity

We could price each component of a project individually. But that would mean every conversation about a small change required unpacking the full structure of collaboration, review, testing, and oversight behind it. The mental load would grow quickly.

So we compress all of that hidden effort into a simple unit: the day. It keeps conversations simple. Charities already carry enough complexity in the work they do.

When digital work is done well, it feels effortless

Pages load quickly. Information appears exactly where people expect it. Forms behave predictably. Users rarely stop to consider what's happening behind the scenes — because the experience simply works.

For charities whose digital services sit at the front door of their organisation — often supporting people navigating difficult circumstances — that reliability isn't just a technical achievement. It's part of delivering the mission itself.

Which brings us back to the original question.

When is an hour not an hour?

It is when those sixty minutes quietly contain the thinking, experience, collaboration, and care required to make something genuinely simple.