Agencies need to be clear that expertise and experience, not delivery, are their differentiator

For the first two decades of my careerI created my first site in 1998 - Flash & inline CSS :), code was deeply expensive to produce, and so we had to be meticulous in the technical decisions we made. Deep upfront planning and thinking helped reduce the risk. We had to carefully plan the building: deciding the materials and each room before we started laying the foundations.

Digital architecture follows real-world architecture. Until suddenly, it doesn’t. With AI, we can start building a Roman Temple then pivot to a suburban semiThis pivot is already possible today. The massive upheaval and re-work this would cause in the real world is collapsing in the digital space.

Tied into a particular CMS? Having legacy systems and tech debt to integrate? These things are becoming much less costly or impactfulThis used to dominate budgets for larger projects.

That doesn’t mean the constraints have gone away. It means they’ve moved up the chain. The biggest challenge isn’t the implementation of code any more. It’s deciding what to build and deciding where the value is.This is genuinely difficult. Over the years I’ve seen clients just grateful to get over the line on big projects. Defining, designing and refining real solutions is hard

When code production becomes cheap, code production will no longer be the bottleneck.this is happening right now A six-month build cycleThese long timeframes used to be dictated by the engineering challenge stops being the expected outcome. Identifying value, picking the right solution, framing the problem correctly, identifying the opportunity: that’s where the agency paradigm has to focus its value.

{brace This is the core - making expert, informed, data-driven decision is the best value and differentiator we can offer clients today} Agencies need to start selling judgment, not delivery capacity, because the value of delivery capacity is no longer the valuable thing. The value proposition is moving. Deciding what to build becomes the hardest partdeciding what to build has always been the most risky and arguable the most challenging part of the project. Building it becomes a commodity. It’s just the output.

Deciding what to build is the hardest part.

As implementation becomes easier and faster, the need to be meticulous in our technical decision-making recedes. This, it seems, is not a safe differentiator to rely on for long.

As it becomes easy to switch from Roman Temple to urban semi, so your initially choice becomes less important.

This is a real opportunity to change our ways of working, to address the shortcomings of agileThis is a throwaway line but is a much bigger topic. The reconciling of fixed, inflexible client needs verses the flexible, backlog-driven ‘if we get to it’ approach has frustrated me for years. Code can become the central thread running through every phase of a project, from the sales pitch, through discovery to the actual build.

With every discipline working into the same core product, we have the chance to remove the friction and disposable artefactsI’ll return to this idea in a later article we’ve had for decades. But this would run alongside a revolution in how we create code.