Web development turns a website or application brief into a working service. Choose the delivery approach through 5 checks: user task, content ownership, integration, acceptance and ongoing responsibility. A website builder, a configured content system and a custom application should be compared against the job they must perform, rather than treated as automatic quality levels.
Which web development approach fits the task?
Define the user journey before discussing a framework. A visitor finding contact details, a buyer completing an order and a customer accessing private documents need different behaviour. Write the starting situation, the action and the expected result. Include what happens when the action cannot be completed. This turns a broad request for a professional website into a brief that can be compared and tested.
Distinguish the work involved. Interface work handles what the user sees and interacts with; server-side work handles the rules and information behind the interaction. Content management determines how authorised people maintain the material. A project may combine these responsibilities in one platform or distribute them across systems. Ask the proposed team to explain the arrangement using the actual journey rather than a list of fashionable technologies.
Compare a hosted builder when the required editing and workflow fit its supported model. Ask for a demonstration of the important task and the owner’s ordinary update process. Do not assume that the ability to assemble a page establishes support for a private workflow, a particular integration or an exit requirement. Record the boundary of what the chosen product is expected to provide.
Compare a configured content system when the project mainly needs structured publishing and established extensions. Inspect the proposed extension set, content model and maintenance ownership. A plugin label is not evidence that the entire workflow is complete. Demonstrate interactions between the relevant components, especially where forms, payments or access rules cross product boundaries. Keep configuration work distinct from custom behaviour that still needs development.
Compare custom development when the task requires behaviour that the proposed off-the-shelf routes cannot adequately demonstrate. Write the missing behaviour and the evidence for that conclusion. Custom work brings responsibility for maintaining the resulting logic; it should not be chosen simply to avoid explaining an existing product. Conversely, do not force a consequential business rule into an unsuitable template merely to minimise initial configuration.
How should acceptance criteria shape delivery?
Make accessibility part of the delivery brief. W3C’s planning guidance recommends integrating it throughout web production. Assign responsibility for content, interaction and evaluation rather than leaving it as a vague final check. A technical implementation can still be difficult to use if the content hierarchy or error explanation is unclear. Test representative tasks with the intended users and appropriate evaluation methods.
Use semantic structure deliberately. W3C’s heading tutorial explains how headings communicate organisation and support in-page navigation. A large bold sentence is not automatically a useful heading structure. Ask whether the page can be understood through its headings and whether sections reflect the user’s task. This is an example of a concrete acceptance observation rather than a subjective instruction to make the page intuitive.
Specify image meaning in context. W3C’s image tutorial distinguishes informative, decorative and functional images. An image used as a button needs an alternative describing its action, while decoration should not produce unnecessary spoken clutter. Include the real purpose of each important image in the content handoff. Do not expect a developer to infer the business meaning from a file name.
Test the journey beyond the successful submission. Include invalid input, repeated action, lost access and an unavailable dependency where relevant. Write the expected state and recovery route before the demonstration. A page that displays an attractive confirmation after a failed request is a functional defect even if the interface looks polished. Keep the observed evidence attached to the acceptance item.
Assign post-handover ownership. Someone must maintain content, review access, renew required services and investigate failures. Record the actual arrangement proposed rather than assuming an agency, host or internal employee owns every task. The handover should identify source assets, documentation and the environment required to reproduce the service. A project is easier to maintain when another competent person can understand those dependencies.
Add a maintenance handover exercise to the acceptance card. Ask a colleague who did not build the prototype to locate the source content, identify the relevant integration and explain where a failed submission would be investigated. Provide the agreed documentation, but do not narrate the answer. Record missing information as a handover defect rather than assuming the builder will always be available. Then repeat a normal content update and confirm that it does not alter an unrelated part of the journey. These tasks test whether the delivery approach supports the business after launch, which is a different question from whether a developer can make the demonstration work.
Decision worksheet
Original contribution: a delivery-approach acceptance card. Put hosted builder, configured content system and custom development in separate columns. Give each the same fictional enquiry journey and a private-document requirement. Record what is demonstrated, what requires configuration and what remains unsupported. Add acceptance cases for invalid input and a user without permission. This comparison makes the missing behaviour visible without assuming that the most complex technology is best. Retain the card with the brief so later design choices can be judged against the original task.
| Checkpoint | Evidence to retain | Decision or corrective action |
|---|---|---|
| User task | Journey, failure case and intended result | Select the approach that can demonstrate it |
| Content ownership | Editor, approval and update process | Avoid an unusable handover |
| Integration | System boundary and exception test | Resolve undocumented dependencies |
| Acceptance | Expected result and observed evidence | Keep defects distinct from preferences |
| Responsibility | Maintenance, access and recovery owner | Close unassigned operational work |
For a worked acceptance conversation, ask the demonstrator to submit a fictional enquiry, introduce an error and show the recovery path. Then ask the intended content owner to change the relevant information without developer assistance. These tasks test both customer use and business maintenance. If either fails, record the specific gap rather than rejecting the whole platform through an undefined impression of quality. The same approach can be applied to a prototype before a full build is commissioned.
See web development for service context and WordPress for one platform route. To discuss a project, get started with the journey and acceptance card.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.