I have been building websites since the AOL era. I have worked with Dreamweaver, open-source e-commerce systems, and platforms including Volusion, Magento, and Shopify. That range is part of why I want to understand the job before choosing the tools.
For a business that needs service information, a few examples, and a reliable inquiry form, a complicated application may introduce more responsibility than value. For a business with customer accounts, live inventory, and unusual workflows, a simple brochure site may be inadequate. I would start with those differences.
Separate content from behavior
A useful first question is whether information needs to change for each visitor or at the moment they request it. Opening hours and a service description can often be delivered as ready-made pages. Account details and order status require a different approach.
Static HTML does not mean a site cannot do anything. It can link to a booking service or submit a form to a server. The important boundary is what runs in the browser, what needs a backend, and where the source of truth lives. I want that boundary to be deliberate.
- 01Explain a service
Ready-made pages plus a secure inquiry endpoint may be enough.
- 02Publish frequently
A content management system can support a regular editing workflow.
- 03Serve live account data
An application backend may be needed for authentication and personalized information.
Give JavaScript a specific job
I am comfortable using JavaScript where it improves the experience. A useful filter, an interactive estimate, or a complex account area may justify it. I would still ask what should happen before the script finishes loading, and what happens if it fails.
Progressive enhancement is a helpful way to think about that question: start with a usable foundation, then add richer behavior. For an inquiry form, that might mean a normal server submission with an enhanced inline response when scripting is available. The server still needs to validate the input; browser validation alone is not a sufficient boundary.
There are applications where that pattern takes more work or is not the best fit. I would make the tradeoff visible instead of claiming every site should use the same architecture.
Performance belongs in the design conversation
A large hero photo, several font files, and third-party widgets are design choices with delivery costs. Before adding them, I would ask what they contribute. Removing an unnecessary widget may be more useful than spending hours tuning code around it.
Images deserve particular attention. I would provide appropriately sized files, reserve their space in the layout, and avoid delaying the image that introduces the page. Images without reserved dimensions can move surrounding content as they load; web.dev documents this source of layout shift. Images farther down a page are better candidates for lazy loading.
Measure the experience, not just the score
I would use performance tools to locate problems, then test the actual tasks. Does the page display its main content promptly? Does a button respond? Does the form remain stable while something loads? A lab score is useful evidence, but it is one test under particular conditions.
For a technical review, I would inspect the network requests, transferred image sizes, render-blocking resources, and the amount of work on the browser's main thread. If real-user measurements are available, I would compare them with the controlled tests rather than assume they tell the same story.
Include the cost of owning the decision
Every additional service or dependency has a future: updates, configuration, failures, and someone who needs to understand it. That does not make dependencies bad. It makes maintenance part of the choice.
I would ask who will edit the site, who will support it, what happens when an integration changes, and how the business can recover from a problem. A slightly more expensive build can be sensible if it reduces recurring work. A sophisticated stack can also be sensible when its capabilities are actually needed.
Good engineering gives a business enough capability to do its job and a realistic way to keep doing it. I want to be able to explain every major piece in those terms. If I cannot, I would reconsider whether it belongs.
