There is a certain kind of building you encounter in old cities that does something to the way you think about the work of construction.
It was built by people who knew they would not see it finished. Who made decisions about foundations and materials and structural principles knowing that the people who would actually use the building, who would live in it or work in it or pass through it every day, had not yet been born. Who understood that the quality of what they were building would be judged not at completion but across decades of use.
This is a different relationship with craft than the one that produces most of what gets built today.
The culture of the deliverable
Most of what gets built now, in software and in digital systems, is optimised for delivery. For the moment when the thing is handed over and the invoice is paid. The measure of quality is whether it works at that moment, whether it looks right at that moment, whether the client signs off at that moment.
What happens after that moment is not the builder’s problem. The contract ends at delivery. The relationship ends at handover. The system is left to whoever inherits it, to operate and maintain with whatever documentation exists, which is rarely enough.
This is not unique to software. It is a general condition of work in an economy that prices output rather than outcomes, that measures completion rather than durability, that treats the long term as someone else’s problem.
But it produces fragile things. Things that work briefly and degrade. Things that depend on the specific knowledge of the people who built them, knowledge that is not written down and leaves when they do. Things that need to be replaced long before they should.
What it means to build differently
Building differently means accepting a different relationship with time.
It means treating the moment of delivery not as the end of the work but as the beginning of the system’s operational life. It means making decisions not based on what is fastest to build but on what will be most reliable and most maintainable over the years ahead. It means writing documentation not as an afterthought but as a core part of the work, because a system that exists only in the builder’s memory is a system that will die with that memory.
It means caring about what happens after you are no longer involved. Which is a strange thing to care about. There is no commercial incentive to care about it, in the conventional sense. The contract ends at delivery. What happens after is not your liability.
But it is your work. And if you care about your work, you care about what it becomes.
The discipline that makes this possible
Building things that last requires discipline before it requires skill. Skill produces things that work at the moment of delivery. Discipline produces things that work years later.
Discipline means defining the architecture before writing the code. It means establishing the rules before the first shortcut presents itself. It means writing the documentation during the build when the decisions are fresh, not after when they are already half-forgotten. It means saying no to requests that would compromise the structure, even when saying yes would be easier and faster.
This discipline is not popular in an industry that sells speed. Fast turnarounds. Quick launches. Agile delivery. These are not wrong values. But they are incomplete values when they crowd out the slower, less visible work of building systems that will still be operating correctly long after the launch celebration.
Why it matters now more than it did
Digital systems have become infrastructure in a way that they were not, even ten years ago. A business’s WordPress platform is not a marketing asset that can be refreshed periodically. It is the primary interface between the business and its customers, the operational backbone of its communications, the platform through which transactions happen and relationships are maintained.
Infrastructure that degrades has consequences that are immediate and measurable. A slow site. A broken checkout. A platform that the team is afraid to touch because nobody knows what will happen if they do. These are not aesthetic problems. They are operational ones.
The standard to which digital infrastructure is built should reflect the role it plays. Which means building it the way you would build anything that matters. With architecture. With rules. With documentation. With the assumption that it will still need to work correctly when the people who built it have long since moved on.
That is not a high standard. It is the standard that serious work has always required. We simply forgot to apply it to software.
