Elements of Scalable Web Development

Part I

Establish — Build and measure a baseline#

Establish creates implementation A and a baseline for the later comparisons. Define what should remain true under pressure, build the common behavior through the approved local single-agent workflow, and record what the first implementation actually does.

I.1 From scalability claims to comparable evidence#

The three chapters form one progression:

  1. What does scalability mean for web development? identifies the maintained goal, relevant pressures, constraints, and evidence a scalability claim would need.
  2. How can coding agents support scalable development? treats the application and its development system as connected systems, with explicit constraints, validation, correction, and ownership.
  3. How can we measure web applications and development workflows? turns runtime behavior and the development process into a repeatable evidence baseline.

Bind implementation A to a declared revision and evidence package so later comparisons can use recorded results.

I.2 Implementation A — Work Activity Tracker#

The Establish project specification defines the implementation and evidence requirements. Choose a domain interpretation, stack, and architecture that fit the common contract and one question you want to investigate. Record the assumptions and trade-offs that later builds should test. Follow the shared transfer policy when carrying material into those fresh implementations.

I.2.1 Instructor perspective — Carry the learning, not the code#

Building the application three times lets you compare development setups and see how growing domain knowledge changes your decisions. That learning is part of the course, even though it complicates causal attribution.

Agents can make a fresh implementation inexpensive enough to abandon a weak product interpretation or architecture. Carry forward the permitted specifications, acceptance material, evidence, and lessons instead of protecting code merely because it took effort to produce. By the third build, you should be better able to judge both the application and the workflow that produced it.

I.3 Implementation discovery lab#

Use this lab to turn the shared specification into a direction to explore. It produces a first project-direction document that you can refine as implementation creates evidence.

Implementation discovery lab

Find a direction worth building three times

The behavior is shared. Your interpretation, stack, architecture, and experiment are yours to choose.

0/4 anchors Begin with the character of your implementation.
Interpret the common brief

Keep the required behavior, but decide what kind of product your version feels like. There is no preferred interpretation.

Need a starting point? Borrow a lens, then change anything you dislike.
Keep the common workspace capability, but choose its meaning and vocabulary: a project, room, run, campaign, class, site, or something else.
Map the required lifecycle to something concrete. It could be a task, job, case, experiment, scene, agent assignment, or repair.
Choose one user and one moment to optimize. This gives the interface a point of view without adding more required features.