What Engineering Taught Me About Building Websites

In engineering, you do not start construction from a sketch on a napkin. You produce specifications, drawings, and calculations that describe what needs to be built, why, and how it connects to everything around it. The people building from those documents need clarity, not creativity.

Web design rarely works this way. Most projects start with a vague brief, a few example sites the client likes, and a designer who starts producing pages. The result is a site that looks appealing but was never specified to achieve anything in particular.

I apply engineering specification discipline to web projects. Before any design work begins, we define: what the site needs to achieve commercially, how visitors will arrive, what they need to understand quickly, and what action they should take. That becomes the specification. Design serves the specification, not the other way around.

Engineers think in systems. A power distribution board is not just a box with circuit breakers. It is a node in a network: upstream supply, downstream loads, protection coordination, fault levels, and future capacity all shape the design.

A website works the same way. Each page exists in a network of relationships: internal links, search intent, visitor journey stages, conversion paths, and content dependencies. A homepage that does not connect logically to service pages, which do not connect to proof, which does not connect to enquiry paths, is a collection of disconnected pages, not a functioning system.

Systems thinking is why I care about site architecture before visual design. The structure determines whether the site works as a whole, not just whether individual pages look good.

Engineering assets are designed for operational life: twenty years for electrical installations, fifty years for structural elements. Nobody designs a substation for the first day it is energised. You design it for the load growth, the maintenance access, the future extensions.

Most business websites are designed for launch day. They look good on the day the invoice is paid. Six months later, the owner needs to add a service, update pricing, or restructure their offer, and the site cannot accommodate it without a rebuild.

I design websites with a realistic lifecycle in mind. That means modular content structures, clean code that can be extended, and architecture that accommodates growth without requiring you to start over. It costs slightly more upfront. It costs significantly less over three to five years.

In engineering, assumptions are stated explicitly and tested. If I assume a cable will carry a certain load, I calculate whether that assumption holds under fault conditions, not just normal operation.

In web design, assumptions are rarely stated at all. The designer assumes visitors will scroll past the hero. The copywriter assumes the value proposition is clear. The developer assumes the form works on mobile. Nobody tests these assumptions until the site has been live for months and enquiries are lower than expected.

I build testing into the process. Analytics, heatmaps, and session recordings are configured at launch. Conversion paths are tested on real devices before handover. Assumptions about visitor behaviour are treated as hypotheses to validate, not truths to decorate.

An engineering project is not complete when the physical work finishes. It is complete when the as-built drawings, test certificates, operation manuals, and maintenance schedules are handed over. The documentation is part of the product.

Most web projects end with a login credential and a "call us if you need anything." The owner has no documentation, no understanding of how the site is structured, and no way to maintain it independently if the relationship ends.

Every website I hand over includes structured documentation: what the site contains, how it is organised, how to update content, and what to do if something breaks. The client should be able to understand their site without calling me. That is a higher standard than most studios set, and it comes directly from engineering practice.

Engineering projects fail when scope is underestimated at tender. A contractor who prices a job without understanding the site conditions, the coordination requirements, or the client expectations will either lose money or deliver a compromised result.

Web projects fail the same way. A designer who quotes four pages without understanding the client's sales process, content requirements, or growth plans will deliver a site that needs rebuilding within eighteen months.

I scope honestly. If a project needs Business or Growth scope, I say so at the consult rather than quoting Starter and managing scope creep later. If a site genuinely suits Starter, I do not upsell. The engineering habit of accurate scoping saves both parties from the most common source of project disappointment.

Engineering did not teach me how to write CSS or configure a server. It taught me how to think about problems before solving them, how to design for the life of a product rather than its first use, and how to communicate clearly with people who depend on my work.

Those habits shape every project at Elphick Digital. The websites I build are not just visually considered. They are architecturally specified, systematically structured, and documented as deliverables. That is what an engineering background brings to web design, and it is why the result tends to last longer and cost less over time than sites built without that discipline.