17 boroughs · 6,084 applications · 4,267 developers · descriptive, not causal.
This paper covers the 17 London boroughs where the applicant's identity is recoverable from the public record: a subset, not all 33. Two boroughs (Barking and Dagenham, Richmond upon Thames) contribute too few joined applications to characterise and are excluded; 16 applications carry no borough. Every figure below is a frequency or an association measured within this 17-borough window. Nothing here should be read as a London-wide rate, nor as a claim about cause.
1The shape of the market
This is overwhelmingly a one-time market. Of the 4,267 distinct developers in the window, 3,168 (74%) appear exactly once, and that One-Shot tier still accounts for 52.1% of the 6,084 applications. The other roughly half is carried by a thin spine of 1,099 repeat developers, splitting into Occasional (2–4 apps; 1,025 developers, 38.5% of applications), Serial (5–9 apps; 62 developers, 6.0%), and Portfolio (10+ apps; 12 developers, 3.4%). A long tail of one-timers sits over a small repeat core.
2Does the system reward repetition?
The intuition under test is that developers who file again and again learn the patch and out-approve newcomers. In this descriptive cut it does not hold. Mean approval rate is flat across the four tiers: 45.3% (One-Shot), 43.8% (Occasional), 46.5% (Serial), 47.1% (Portfolio). The clean contrast is one-shot developers approving at 45.26% (n = 3,168) against repeat developers at 44.01% (n = 1,099), a gap of −1.24 percentage points. Repeat status is not associated with higher approval in this descriptive window; if anything the repeat cohort sits marginally lower. This is a frequency comparison, not a controlled test, and repeat players may also self-select into harder sites.
Repeat applicants do not out-approve one-timers in this 17-borough cut. One-shot n = 3,168; repeat n = 1,099. Descriptive association only, not evidence that experience is without value, and not adjusted for site difficulty.
3Developer behaviour over time
Order each repeat developer's applications by the date they were registered and approval rises across the sequence, from 37.2% on the first application to 50.2% on the last (n = 309 developers with ≥3 applications; 84 went refused-first to approved-last, 44 the reverse). This looks like a within-developer climb, but it does not overturn the flat −1.24pp cross-sectional gap from the previous section. The first application of a repeat developer (37.2%) sits below the one-shot rate (≈45%): refusal is what produces a repeat applicant, so the repeat cohort is negatively selected and then climbs back toward ≈50%. Two caveats sit on top of this and stay unresolved. The first is "stop-on-success": developers stop filing once they win, which enriches the last-application slot with eventual winners. The second is the entanglement of learning with regression-to-the-mean. The cause stays open.
Among the 309 developers with at least three applications, approval rises from the first filing (37.2%) to the last (50.2%). 84 developers went refused-first to approved-last; 44 went the other way. Read this as an association across the sequence, not as evidence that experience itself raised the odds: the first-application rate sits below the one-shot rate (≈45%), so repeat developers are a negatively selected group climbing back toward the middle. "Stop-on-success" inflates the last-application figure, and learning and regression-to-the-mean are entangled; the cause stays open.
No: persistence, not exit, is the modal response to a harder borough. Across the 15 boroughs with at least 50 joined applications, borough difficulty (the mix-adjusted approval differential; more negative = harder) shows no significant association with the share of one-shot developers (r = −0.07), with applications per developer (r = +0.15), or with the comeback-after-refusal rate (r = −0.35, p = 0.20). Multi-borough repeat developers (n = 126) do not flee to easier patches: they place their volume at a mean difficulty of −2.9pp, against a −1.5pp baseline for repeat developers generally, if anything slightly harder ground. Read this as descriptive and underpowered (n = 15 boroughs).
4The repeat-player tendencies
The groups below come from k-means (k = 5) on the 309 developers with at least 3 applications, across 11 behavioural features. Separation is weak (silhouette ≈ 0.17). A second method (HDBSCAN) independently found no dense clusters, and a stability check on the ≥5-app cohort (n = 74) gives silhouette ≈ 0.22. The honest reading: developer behaviour here is closer to a continuum than a set of crisp types. Treat what follows as indicative tendencies, not hard archetypes.
Cluster the 309 repeat developers on their behavioural fingerprints and five loose groups fall out, plotted below by centroid. None is a crisp type, so read each as a tendency rather than a category. Their fingerprints still read distinctly enough to describe by behaviour, never by any real developer.
Reading the centroids gives five recognisable patterns. Group A (n = 29), the conservation-patch specialists, concentrate in conservation areas (92% of sites) within a single borough and resubmit often (59%), approving at 52.2%. Group B (n = 49), fully self-represented with no agent, skew towards single-unit schemes and show the highest approval (57.7%) on the lowest resubmission rate (33%). Group C (n = 70) are single-unit specialists, single-unit-dominated (77%) and single-borough, approving at 46.2%. Group D (n = 74), the multi-unit single-patch builders, put up the largest schemes (median 5.3 units), almost never single-unit, on the tightest single-borough focus, approving at 49.5%. Group E (n = 87) is the multi-borough scattergun: the most boroughs per developer (2.69), the highest site-type diversity, the highest pre-app use (24%), and the lowest approval (29.8%). Every one is a tendency, not a stable archetype (silhouette ≈ 0.17).
Tendency table
| Group (n) | Approval | Median units | % single-unit | Boroughs | % conservation | Pre-app rate | Resub rate |
|---|---|---|---|---|---|---|---|
| A: conservation patch (29) | 52.2% | 3.5 | 29.2% | 1.21 | 92.2% | 9.8% | 58.7% |
| B: self-represented (49) | 57.7% | 2.4 | 44.8% | 1.41 | 3.4% | 10.0% | 32.7% |
| C: single-unit (70) | 46.2% | 1.3 | 76.6% | 1.24 | 3.0% | 7.0% | 46.0% |
| D: multi-unit single-patch (74) | 49.5% | 5.3 | 1.2% | 1.04 | 0.9% | 4.5% | 52.9% |
| E: multi-borough scattergun (87) | 29.8% | 2.5 | 33.8% | 2.69 | 12.4% | 24.2% | 34.6% |
Group names are descriptive labels for fingerprint tendencies, not identifiers of any real developer. All entities are hashed. Cluster centroids from clusters.centroids; sizes from clusters.sizes (29 / 49 / 70 / 74 / 87 = 309). Boroughs column shows mean boroughs per developer (n_boroughs).
5What this can and cannot tell you
Scope is 17 of 33 boroughs. Applicant identity is recoverable only where the public record names a distinct developer. These 6,084 applications and 4,267 developers are that window, not London as a whole. Read no figure here as an all-London rate.
Approval rates carry their n. Tier and group rates are stated with their cohort size. The Serial (n = 62) and Portfolio (n = 12) tiers, and every cluster group, are small; their rates are indicative, not precise.
The clusters are weak. k-means separation is faint (silhouette ≈ 0.17), HDBSCAN found no dense groups, and the ≥5-app stability check reaches only silhouette ≈ 0.22 (n = 74). Behaviour is closer to a continuum than to crisp types. The five groups are indicative tendencies.
Descriptive only. Every claim is a frequency or an association measured in this window. Nothing here is causal or predictive. The repeat-vs-one-shot result is "not associated with higher approval": it is not a finding that experience is without value, and it is not adjusted for site difficulty or selection.
Identities are hashed. Developers are grouped by a hashed key; no real applicant is named or identifiable. Groups are characterised by behaviour, never by name.