Elements of Scalable Web Development

Introduction

Elements of Scalable Web Development#

Created
Updated

Architecture, measurement, scaling pressure, and agentic workflows

Scalability describes the relationship between changing pressure and the behavior people expect a system to maintain. For a web application, that pressure may come from users, data, traffic, failures, geography, or new requirements. The response may involve architecture and infrastructure, but it can also change cost, complexity, ownership, and the speed at which the application can evolve.

This book therefore studies two connected systems. The first is the web application that receives requests, moves data, preserves authority, and produces browser-visible behavior. The second is the development system of people, agents, tools, instructions, tests, and review that changes the application. Scaling one while ignoring the limits of the other does not create a scalable project.

The central question is how application behavior and the development process can continue to meet their goals as pressure grows.

Sustainability angle

Scalability also has an environmental dimension. More traffic, more data, more retries, more logs, and more infrastructure all consume resources. Throughout the book, you can ask whether a design scales efficiently, not only whether it scales at all.

0.1 Why this book now#

If I had written this book only a few years ago, it would have focused strictly on web technologies rather than development itself. Coding agents changed that. Developers can now delegate substantial parts of implementation, moving more of their attention toward specification, architecture, validation, and ownership. Agents are also becoming consumers of web applications through browsers, APIs, and tools. This step up in abstraction brings its own opportunities and challenges, and this book examines how web development changes when agents participate on both sides of the application boundary.

During the past few months, I have developed projects whose complexity would previously have kept me from attempting them. The case studies examine several of them, including Slideotter, Kirjolab, Thesis Journey Tracker, and this book's own development system. Each taught me something different: generation can outpace product judgment, architecture can lag behind implementation, and deliberately narrow scope can turn the same capability into dependable software. Reading about other people's experience helps, but there is also value in making bounded mistakes of your own and forming your own judgment.

While the book was developed to support a course I run at Aalto University, I have tried to keep the chapters independent so that you can use it as reference material. The course project complements the book and lets you experience different ways of developing web applications with agents.

0.2 How this book was made#

I developed this book with GPT-5.5 and GPT-5.6 through the iterative human–agent workflow it studies. The collaboration let me explore more material and build interactive demonstrations; validation and curation remained my central editorial work. The book's case study examines that process and its evidence limits. The online edition remains a living book whose feedback tools support continuing review.

0.3 One application, three development systems#

The course project implements the same Work Activity Tracker specification three times. The required browser-visible behavior remains substantially stable while product interpretation, stack, rendering, storage, interfaces, and architecture remain open to justified choices.

Each phase begins from a fresh implementation and changes the development setup deliberately:

  1. Establish: a locally hosted model in a single-agent workflow produces implementation A and its evidence baseline.
  2. Challenge: a foundation model in a single-agent workflow produces implementation B while the course exposes architectural assumptions and development friction.
  3. Compare: a declared agent fleet produces implementation C before all three applications and development workflows are compared.
One application, three development systems A shared Work Activity Tracker specification feeds three fresh implementations. Domain knowledge, evidence, and development skill accumulate from Establish through Challenge and Compare, while application code and implementation-specific tests do not carry between builds. The three results are compared at the end. SHARED ACROSS EVERY BUILD One Work Activity Tracker specification Acceptance material · pressures · reporting categories PHASE 1 · ESTABLISH Implementation A Local model Single-agent workflow FRESH CODEBASE PHASE 2 · CHALLENGE Implementation B Foundation model Single-agent workflow FRESH CODEBASE PHASE 3 · COMPARE Implementation C Declared agent fleet Multi-agent workflow FRESH CODEBASE FINAL REFLECTION Compare three builds and development systems Reflect on evidence,trade-offs, and fit Fresh implementation each phase: application code and implementation-specific tests do not carry forward
The task stays comparatively stable while the development system changes. Learning accumulates; application code does not.

The comparison is bounded rather than perfectly controlled. You enter each later phase with greater domain knowledge; implementations may make different design choices, and model or tool configurations can change. The shared specification, acceptance material, pressures, and reporting categories make those differences discussable without pretending that the course establishes a universal ranking.

Each main chapter ends with a Project artifact section. These sections are staged checkpoints for building the current phase's evidence; they do not silently create separate submissions. The common project specification and current phase specification provide the authoritative deliverable checklist, and one clearly structured artifact may satisfy several chapter checkpoints.

Protect learning, not only output

Immediate task performance is not the only outcome worth protecting. Across three randomized experiments involving short arithmetic and reading-comprehension tasks, brief AI assistance improved work while it was available but reduced later unaided performance and persistence. In a cross-sectional subgroup analysis of the second experiment, participants who reported using AI for direct answers later performed worse and skipped more than both the control group and those who reported using it for hints (Liu et al., 2026). These tasks do not establish the long-term effect on professional programming, but they support a practical course rule: use agents for hints, critique, and verification when the underlying skill must remain yours.

0.4 How the argument develops#

0.4.1 Establish — Build and measure a baseline#

  1. What does scalability mean for web development? defines scalability through maintained goals, pressures, constraints, and evidence.
  2. How can coding agents support scalable development? examines how intent, authority, validation, correction, and ownership shape agent-assisted work.
  3. How can we measure web applications and development workflows? creates comparable runtime and development evidence for implementation A.

0.4.2 Challenge — Expose architectural assumptions#

  1. How does web architecture shape scalability? traces how responsibility moves across servers, cloud, edge, rendering, data, and caches.
  2. How does development friction limit web projects? follows the cost of changing one web behavior across those boundaries.
  3. Which web application assumptions fail under pressure? uses documented incidents and the course project to connect failed assumptions, signals, and recovery.

0.4.3 Compare — Evaluate workflows and scaling responses#

  1. When do agent fleets improve web development? grows one agent into a bounded fleet and makes correction part of the workflow.
  2. How should web applications respond to scaling pressure? selects architectural responses from measured limits rather than from a technique catalog.
  3. What do three agent-assisted implementations teach us about web scalability? synthesizes a justified target architecture and development workflow from the three builds.

The main chapters provide the shortest path through the argument. The appendices preserve deeper evaluation methods, implementation details, security controls, and formal models for readers who need them.

0.5 References#

  1. Liu, G., Christian, B., Dumbalska, T., Bakker, M. A., & Dubey, R. (2026). AI Assistance Reduces Persistence and Hurts Independent Performance. arXiv Preprint arXiv:2604.04721. https://doi.org/10.48550/arXiv.2604.04721