Web Development Handbook

The role of web development in web engineering

Web development is the point where analysis, requirements and design become working systems. It is not about using the newest framework; it is about delivering stable, understandable and testable behaviour that supports the real goals of the site.

In the Dianthos approach, development was guided by a few simple questions:

• Can another developer understand and safely modify this code six months later?
• Can the site be moved, backed up and restored without surprises?
• Does the implementation respect the design and content structures agreed earlier?
• Can we measure what is happening in production and act on it?

Everything else—frameworks, libraries, tools—was chosen in service of these questions.

Architecture & platform choice

Not every project needs a custom application. Choosing between static pages, a CMS-based site or a bespoke web app is one of the most important early decisions.

Typical options we considered

• Static websites. Suitable for small sites with stable content and few updates. Simple, fast, secure and easy to host.
• CMS-based sites (for example Joomla, WordPress). Appropriate when non-technical editors need to update content, manage pages and publish articles without developer intervention.
• Custom web applications. Needed when business logic or workflows are specific and cannot be expressed cleanly through existing CMS functionality or extensions.

Questions before deciding

• Who will maintain content and for how long?
• What integrations (payments, APIs, external systems) are required?
• How often will features change?
• What is the realistic budget for implementation and ongoing support?

The simplest platform that fits the requirements is usually the right starting point.

Code organisation, templates & components

Whether using a CMS or a custom framework, structure matters. Clear separation of concerns prevents small changes from breaking unrelated parts of the site.

Principles we applied

• Templates for page types. Distinct templates for key page categories (home, listing, detail, forms) rather than a single catch-all layout.
• Reusable components. Navigation, footers, call-to-action blocks, cards and forms implemented as reusable pieces, not copied fragments.
• Configuration over duplication. Where possible, behaviour was controlled via configuration or options instead of creating slightly different copies of the same code.
• Minimal logic in templates. Business logic lived in controllers, helpers or services — templates focused on presentation.

Well-structured templates made it easier to adjust design and content without rewriting core functionality.

Data, databases & integrations

Many projects required structured data: product catalogues, article archives, bookings, user accounts or custom records. Integrations with external systems (APIs, payment gateways, third-party services) were common.

Working with data

• Designing database schemas around clear entities and relationships.
• Separating content data (articles, pages) from configuration data where possible.
• Ensuring there was a defined process for imports, exports and backups.
• Implementing validation at both the form and server layers.

Integrations

• Wrapping external API calls in dedicated modules or services.
• Handling timeouts, errors and retries gracefully.
• Logging key interactions for troubleshooting and support.
• Ensuring that the site remained usable if an external service degraded.

Good data design simplified reporting, changes and future migrations.

Performance, security & reliability

Performance and security were treated as part of development, not as late-stage additions.

Performance habits

• Minimising unnecessary queries, loops and heavy operations.
• Using caching where it made sense (page, fragment or query caches).
• Optimising images and static assets before deployment.
• Measuring real load times instead of relying on local impressions.

Security basics we applied consistently

• Keeping CMS cores, plugins and libraries updated.
• Validating and sanitising all user input.
• Using prepared statements for database interactions.
• Restricting administrative interfaces and enforcing strong credentials.
• Configuring backups and verifying that restores actually worked.

Many incidents can be avoided by following a small set of simple, repeatable practices.

Environments, deployment & version control

Even small projects benefit from a clear separation between development, staging and production, and from tracking changes properly over time.

Environments

• Development. A local or shared environment where work could be done freely.
• Staging / testing. A space that mirrored production closely, used to validate changes with realistic data.
• Production. The live environment, where changes were applied deliberately and usually in small batches.

Deployment & version control

• Using version control (for example Git) for code and configuration where possible.
• Documenting deployment steps and automating them as projects grew.
• Keeping environment-specific settings out of the codebase when feasible.
• Tagging or noting versions so that rollbacks were possible when required.

Predictable releases reduced downtime and made troubleshooting more straightforward.

Maintenance, support & lifecycle

Every web project has a lifecycle: initial launch, growth, changes in requirements and, eventually, replacement or consolidation. Development decisions should make each phase manageable.

Planning for the future

• Documenting key technical decisions and dependencies.
• Keeping extensions and custom code as simple and well-isolated as possible.
• Providing basic administration notes for content editors and site owners.
• Scheduling periodic technical reviews (updates, performance, security checks).

Many issues seen in long-running sites were not caused by dramatic failures, but by a series of small, undocumented changes. A modest discipline around maintenance prevented most of them.