Våra städer har ett API-problem. Startups kan fixa det.

"Städer är tekniska artefakter," Kevin Kelly skrev en gång, "den största tekniken vi gör." Tänk om vi tittade på Amerikas städer inte metaforiskt som teknik, utan bokstavligen som ett tekniskt system?

Istället för att slåss om politik skulle vi ställa våra städer de vardagliga frågor som ingenjörer och entreprenörer ställer om någon annan teknik: "Är det dyrt att driva det?" "Skalar den? Och särskilt: "Hur bra är dess API:er?"

Städernas API-utmaning: policy för markanvändning

I grund och botten beskriver ett API ("applikationsprogrammeringsgränssnitt") hur användare interagerar med en teknologi. API:er ger struktur och sätter förväntningar – användare vet vad de får och hur de ska få det.

Stadens kärna API är dess markanvändningspolitik. Genom kommunfullmäktige, planeringskommissioner och andra byråer tillhandahåller stadsförvaltningar API:et runt vår byggda miljö. Om du vill bygga i Amerikas städer måste du integrera med deras Land Use API. Dagens markanvändnings-API:er är mer papper än digitala, men de delar en grundläggande form med onlinesystem: data in, bearbetning med algoritm, svar ut. Fastighetsutvecklare, krögare och andra byggare skickar in data som arkitektritningar och miljörapporter. Staden behandlar dessa uppgifter och returnerar ett svar. Tillstånd att bygga … eller inte.

Precis som digitala API:er strukturerar vår upplevelse online, strukturerar Land Use API:er den fysiska världen. De bestämmer vad som byggs, var och av vem. Markanvändnings-API:er som gör det svårt att bygga ligger bakom några av våra största problem: bostadskostnader, hemlöshet, och även till synes orelaterade frågor som fetma och låga födelsetal.

Hur mäter sig amerikanska städer som teknik?

Ingenjörer bedömer API:er på hastighet, enkelhet och tillförlitlighet.

Bra API:er är fast. Amerikanska städer, å andra sidan, är notoriskt långsamma med att ge tillstånd att bygga. Förfrågningar till dessa API:er mäts i månader, år eller till och med årtionden.

Bra API:er är enkla. Amerikas API:er för markanvändning är mycket komplexa. Redan innan data träffar API:et måste den överensstämma med komplexa specifikationer för zonindelning, design och mycket mer. För att uppfylla API:s krav måste även små projekt spendera tiotusentals dollar för att förbereda data. Ännu värre är att data inte är standardiserade. Varje stad kräver olika data i olika format optimerade för olika (ofta till synes godtyckliga) faktorer.

Bra API:er är förutsägbara och pålitliga. Amerikas API:er för markanvändning plågas av slumpmässighet. När väl byggare uppfyller svåra API-krav finns det ingen garanti för att en stad kommer att ge tillstånd. När de väl har fått data från en byggare bjuder många städer bokstavligen in irrationella motståndare till förändring och personer med ett direkt ekonomiskt intresse av att blockera byggare för att strypa framsteg. Algoritmerna i kärnan av amerikansk markanvändning är så opålitliga att de är mål för internetsatir:

Utomstående förstår inte riktigt hur konstig planeringsprocessen är.

Föreställ dig att du är en snickare. Du har byggt möbler och handläggning i många år. Du har en stil som du har utvecklat och en lojal kundbas som älskar dina produkter...

— din lokala självförvållade bostadskris ouroboros (@itsahousingtrap) Juli 29, 2022

Amerikas städer är en teknik insvept i ett trasigt API.

Hur man fixar städers API-problem

De flesta människor fokuserar på politiska eller juridiska lösningar på USA:s trasiga API:er för markanvändning. I hans bok Markanvändning utan zonindelning, juridikprofessor Bernard Siegan argumenterar för att amerikaner borde ta städer till Högsta domstolen för deras dysfunktionella markanvändning. Men även om denna svåra juridiska förändring lyckades, skulle den bara berätta för städerna vad inte att göra.

Precis som med andra teknologier är startups vårt bästa hopp om innovation. Nystartade företag måste konkurrera direkt med äldre städer för att erbjuda bättre markanvändnings-API:er till Amerikas byggare. I praktiken innebär detta att startups bör köpa stora landområden och bygga hela stadsdelar och till och med städer.

Tanken att startups skulle kunna bygga stadsdelar eller städer låter långsökt, men det är en gammal amerikansk tradition. Från järnvägsboomstäder, till Las Vegas, till köpcentra i storstadsstorlek, till Walt Disney World, till de första förorterna, USA:s historia är rik på pionjärer som format vår byggda miljö inte bara med en enda byggnad, utan genom att äga och driva komplexa samhällen . Grundare, beväpnade med disciplinen och den tekniska kapaciteten hos moderna startups, måste återupptäcka denna amerikanska tradition och bygga startup-städer.

Dessutom är det bra att bygga markanvändnings-API:er. Berättelsen om Vail Resorts handlar inte bara om skidåkning, utan också om kontrollera markanvändningen nära vackra skidbackar. Irvine Company byggde Irvine, Kalifornien till 300,000 XNUMX invånare genom kontroll av dess markanvändnings-API. Howard Hughes Corp. har byggt några av USA:s topprankade och mest lönsamma samhällen genom att köpa stora tomter och kontrollera Land Use API inuti det.

Även om programvara ensam inte kommer att fixa Amerikas städer, mjukvara Kan effektivisera byggprocessen för nystartade städer.

Till exempel kan nystartade städer skapa en enkel datastandard för byggnadsförslag, liknande den Open Graph or JSON-LD standarder som används på internet. En sådan standard – som kan vara lika enkel som CAD-filer med metadata – innebär färre skräddarsydda Powerpoint-presentationer och tusentals dollar sparade på konsultarvoden.

Nystartade städer kan också erbjuda byggare mjukvaruarbetsflöden kopplade till verklig mark. Liknande SpaceMaker, Gräva, fotogen, or Husmor, kan en nystartad stad koda in sin föredragna estetik och andra kvaliteter i en maskininlärning eller annan generativ modell. Byggare kan justera parametrar för att skapa nästan oändliga design för deras användningsfall. Startstäder kan förbinda sig att automatiskt godkänna allt som genereras av deras programvara.

Medan äldre städer förbjuder många idéer direkt, kan startstäder ange enkla regler - liknande formulärbaserade koder – som tillåter vilken byggnad som helst så länge den fungerar under vissa gränser för olägenheter som ljud eller lukt. Om en framtida automatiserad fabrik kan arbeta tyst och utan föroreningar, varför ska vi då förbjuda den från stadsgränserna?

Ribban är så låg i den här branschen att även grunder som omtänksam kundservice skulle vara stora innovationer. B2B-programvarustartuper investerar i Customer Success-team, som hjälper kunder att använda sin teknik. Varför skulle inte nystartade städer erbjuda "Builder Success Teams", som fungerar som en concierge för dem som vill bygga?

Mjukvarustartuper gör också offentliga åtaganden om hastigheten och kvaliteten på sina API:er. I en värld där byggare möter år av förseningar och tvetydiga tidslinjer, skulle ett offentligt åtagande att "48 timmar eller mindre" för tillstånd att bygga vara ett radikalt erbjudande – startup city-versionen av en Service Level Agreement eller "pengarna-tillbaka-garanti".

Den största skillnaden mellan äldre städer och nystartade städer är att startups vill tillväxt. Denna grundläggande förändring av incitament kan släppa lös innovation i programvaran och tjänsterna som driver USA:s byggda miljö.

Vi kan inte bygga framtiden om vi slutar bygga städer. Som i alla andra branscher kommer det bara att gå så långt att be äldre företag att göra det bättre. För att fixa Amerikas städer måste en ny generation grundare bygga startups som direkt konkurrerar med dem.

Upplagt 13 september 2022