How do you classify a web project before it exists?

A “blog” may be a publication series, a paid archive, a multi-author community, or just one section of a larger service. A “portal” may be a catalogue, a customer workspace, a place to submit cases, or a bundle of independent products. “SaaS” describes a delivery and billing model, not the functional outcome.

The problem is not that these words are useless. They are helpful entry points into market language. They fail only when we ask them to determine persistent state, a binding operation, autonomous participants, integration, moderation, or another concrete obligation.

So the method does not begin with “what kind of website is this?”. It asks: “what outcome must exist before the client can accept this part of the project?”.

• Page form does not determine function.
• A business model is not a functional archetype.
• Technology does not replace an acceptance criterion.
• One market label may conceal several independent modules.

A template answers the practical question “what can I start building from?”. It may mix industry, style, technology, and function because its purpose is speed. A taxonomy has a different job: let two people follow the same reasoning path, name the difference between candidates, and preserve why a decision was made.

The unit of classification is a functional module: a part of the project with its own required outcome, a separate acceptance criterion, and the ability to be named and classified independently. A module need not match a screen, repository, or technical service.

An atomic project has one module. A composite project has at least two. Sign-in, payment, supporting search, export, AI, and an ordinary admin panel remain features or modifiers unless they pass the full module test.

• Its own explicitly required domain outcome.
• A separate acceptance criterion, not merely a delivery mechanism for another outcome.
• The ability to be named and classified independently.

Classification by form is useful for finding inspiration. Industry suggests language and regulatory risks. Technology helps plan execution. Audience reveals access boundaries. Job-to-be-done brings us closer to human motivation. But none of these axes alone ensures that two projects with the same label share the same condition of acceptance.

Version 3.0 uses the outcome contract as its organising axis: what must be published, computed, established, maintained, or coupled between parties. The other axes do not disappear. They return as facets, modifiers, brief inputs, or glossary entry points.

The scope gate comes first: the primary interface must run in a browser at a URL, and a meaningful reference implementation must fit the method's operational limit. The module test then separates independent outcomes.

Only then do we read N → P → O → R. The first “yes” selects a family. N asks about autonomous participants or a shared pool of their contributions. P asks whether work on the same object continues in a later session. O asks about a binding effect with the operator. R asks whether user data materially determine the outcome. Four “no” answers lead to the publishing family.

The order does not merge outcomes that already passed the independent-module test. If two outcomes have their own acceptance criteria, they receive two paths even when one depends on the other.

• N: autonomous parties or their shared pool of contributions.
• P: a persistent domain object continued across sessions.
• O: a binding operation with the operator.
• R: an outcome materially determined by current-session data.

A publishing service delivers content selected or arranged by an operator. A session tool produces an outcome, change, or course determined by current input. An operator-operations service establishes a binding effect. A persistent-workspace app lets someone continue an object. A multi-sided platform couples autonomous participants or their contributions.

Each family has its own predicates. A tool, for example, may control an external state, make an accurate claim, create an artifact, select an existing object, deliver a message, or be an experience in itself. Precision comes from boundaries between leaves, not from multiplying fashionable labels.

The tree has no “Other” class. If no leaf fits literally, the method records a terminology gap instead of hiding it under the nearest name.

After selecting a leaf, the method records M1–M11 modifiers, U1–U4 audiences, D1–D7 data sources, the T1–T4 execution model, and — for a persistent workspace — the S1–S3 source of authoritative change. The axes remain separate because they answer different questions.

M10 does not simply mean “hard”, T3 does not mean “modern”, and more codes do not automatically create a higher project level. Codes preserve concrete obligations: tenant isolation, moderation, a source of truth, route rendering, or change-merge rules.

A quick estimate may use the union of modifiers, but responsibility stays with the module. A payment risk in one outcome is not mechanically assigned to the whole project.

One leaf per module makes results comparable, but puts pressure on correct outcome decomposition. A priority key resolves consistently, but weaker roles must be preserved as secondary contracts and effects. A hybrid structure is richer than a flat list, but asks the reader to complete several steps.

There are empirical limits too. Observational warrant comes from recognisable service and template catalogue patterns, not a statistically representative corpus. M10 signals an elevated obligation, but does not replace a data and jurisdiction profile. An unclear brief can still lead two teams to decompose modules differently.

These costs are not hidden. The module test, boundary questions, explicit terminology gaps, and an auditable answer trail reduce discretion without pretending to eliminate it.

The brief requires finding existing insurance offers, diagnosing flood risk, and producing a ready-to-use protection plan. The API and redirect matter, but do not determine the type of the whole project.

Each outcome has its own acceptance criterion: a relevant selection of an existing offer, an accurate diagnosis, and a usable new artifact. The result is a composite profile, while the diagnosis → plan dependency does not merge two outcomes into one module.

Take one sentence from a brief and add its condition of acceptance. Test whether it is an independent module. Walk through N, P, O, and R without guessing, then choose a leaf within the family. Finally, record only the facets that genuinely follow from the requirements.

If the answer is “I don't know”, do not replace it with intuition. Keep it as a brief question. If two outcomes are independently acceptable, do not force one type. If no leaf fits, record a gap. Those moments often reveal the most about the project.