What Building Software for Complex Engineering Workflows Taught Me

The first thing you learn when building software for engineering workflows is that your users do not tolerate unreliability. A web designer whose portfolio site has a broken link loses nothing. An engineer whose document control system loses a transmittal record has a genuine project problem.

Working with users who depend on your software daily creates a different standard. You test more carefully. You think about edge cases. You design for the worst scenario, not the demo scenario. You learn that "it works on my machine" is not an acceptable standard when someone else's work depends on your code.

That habit of building for reliability, not just functionality, is something I bring to every web project. A business website that breaks on mobile, loads slowly on a regional connection, or loses a form submission is not just annoying. It is a lost opportunity that the business may never know about.

Engineering software handles data that matters. Cable schedules feed into procurement. Document transmittal records are legal evidence of what was issued and when. Compliance trackers determine whether a project meets its regulatory obligations.

Working with this kind of data teaches you that data integrity is not a feature. It is a foundation. You design your database schemas carefully. You validate inputs rigorously. You build audit trails so you can trace what changed, when, and why. You never assume data is clean, and you never trust user input without verification.

Most websites handle less critical data, but the principles transfer. Form submissions should be validated server-side, not just client-side. Customer data should be stored securely and backed up reliably. Analytics data should be accurate enough to base decisions on. The discipline of treating data seriously produces better outcomes regardless of the domain.

When engineers describe what they need from software, they describe workflows: "I need to create a transmittal, attach documents, send it to the client, and track their response." They do not ask for a "transmittal creation feature" and a separate "document attachment feature" and a separate "client notification feature."

But that is how most software is built: feature by feature, without considering how those features connect into the workflows users actually follow. The result is software where every individual feature works but the overall experience is fragmented and slow.

I learned to design around workflows rather than features. For a website, this means thinking about visitor journeys rather than individual pages. How does someone move from discovering the business to understanding the service to seeing proof to making contact? That is a workflow. Design the system to support it, and the individual pages follow naturally.

Engineering software is inherently complex. A cable scheduling system needs to handle multiple cable types, installation methods, routing paths, termination details, and testing records. The underlying domain is complex, and the software needs to manage that complexity.

But managing complexity does not mean the software itself should be complex. The best engineering software I built took complex workflows and made them feel simple. It hid the complexity behind clear interfaces, sensible defaults, and logical step-by-step processes.

Websites face the same challenge on a different scale. A business with twelve services, four locations, and three customer types has a complex offering. The website needs to present that complexity in a way that feels simple: clear navigation, logical grouping, and progressive disclosure that gives visitors detail only when they ask for it.

Building software for colleagues taught me the value of short feedback loops. I would release a feature, watch engineers use it the next day, hear their feedback over coffee, and iterate within the week. There was no six-month development cycle followed by a big reveal. There was continuous delivery and continuous feedback.

That approach transfers directly to web development. I prefer to launch a solid foundation and iterate based on real visitor data rather than spending months perfecting a site that has never been tested with real users. Analytics, heatmaps, and session recordings provide the feedback loop. Regular content updates and structural improvements provide the iteration.

A website that improves monthly based on evidence will always outperform a website that was "perfected" at launch and never touched again.

In engineering, you sign your work. A Chartered Professional Engineer who stamps a drawing is personally accountable for its accuracy and compliance. That standard creates a culture where quality is not aspirational but obligatory.

I carried that standard into software development. Code should be clean, well-structured, and maintainable by someone other than the original developer. It should follow established patterns, handle errors gracefully, and be documented where the logic is not self-evident. These are not nice-to-haves. They are professional obligations.

For the websites I build, this means the client receives a codebase that another developer could understand and maintain if needed. It means the code is not a liability if the relationship ends. It means the quality is in the engineering, not just the visual presentation.

The websites I build at Elphick Digital are not engineering software. They do not manage cable schedules or track compliance. But they are built with the same habits: reliability first, data integrity by default, workflow-driven design, managed complexity, continuous improvement, and code quality as a professional standard.

Those habits are difficult to develop from web design alone, because the consequences of poor web design are usually invisible. A broken form submission is a lost enquiry the business never knew about. A slow page is a visitor who left without the business noticing. Poor code is a problem that only surfaces when someone needs to change something.

Engineering taught me to build for the consequences I cannot see. That is probably the most valuable thing it taught me about building anything.