Onze steden hebben een API-probleem. Startups kunnen het oplossen.

"Steden zijn technologische artefacten", Kevin Kelly schreef ooit: "de grootste technologie die we maken." Wat als we de Amerikaanse steden niet metaforisch zouden zien als technologie, maar letterlijk als een technologisch systeem?

In plaats van te vechten over politiek, zouden we onze steden de alledaagse vragen stellen die ingenieurs en ondernemers stellen over elke andere technologie: "Is het duur om te gebruiken?" “Schaalt het? En vooral: “Hoe goed zijn de API’s?”

De API-uitdaging van steden: beleid inzake landgebruik

In wezen beschrijft een API ("application programming interface") hoe gebruikers omgaan met een technologie. API's geven structuur en stellen verwachtingen - gebruikers weten wat ze krijgen en hoe ze het kunnen krijgen.

De kern-API van de stad is zijn landgebruiksbeleid. Via gemeenteraden, planningscommissies en andere instanties leveren stadsbesturen de API rond onze gebouwde omgeving. Als je in de steden van Amerika wilt bouwen, moet je integreren met hun Land Use API. De landgebruik-API's van vandaag zijn meer papier dan digitaal, maar ze delen een fundamentele vorm met online systemen: data in, verwerking door algoritme, respons uit. Vastgoedontwikkelaars, restaurateurs en andere bouwers dienen gegevens in zoals bouwtekeningen en milieurapporten. De gemeente verwerkt deze gegevens en stuurt een reactie terug. Toestemming om te bouwen … of niet.

Net zoals digitale API's onze ervaring online structureren, structureren API's voor landgebruik de fysieke wereld. Zij bepalen wat er gebouwd wordt, waar en door wie. Landgebruik-API's die het moeilijk maken om te bouwen, liggen achter enkele van onze grootste problemen: woonlasten, dakloosheid, en zelfs schijnbaar niet-gerelateerde problemen zoals: obesitas en lage geboortecijfers.

Hoe scoren Amerikaanse steden als technologie?

Ingenieurs beoordelen API's op snelheid, eenvoud en betrouwbaarheid.

Geweldige API's zijn fastukken. Amerikaanse steden daarentegen zijn notoir traag met het verlenen van toestemming om te bouwen. Verzoeken aan deze API's worden gemeten in maanden, jaren of zelfs decennia.

Geweldige API's zijn eenvoudig. America's Land Use API's zijn duizelingwekkend complex. Zelfs voordat gegevens de API bereiken, moet deze voldoen aan complexe specificaties van zonering, ontwerp en nog veel meer. Om aan de eisen van de API te voldoen, moeten zelfs kleine projecten tienduizenden dollars uitgeven om gegevens voor te bereiden. Erger nog, gegevens zijn niet gestandaardiseerd. Elke stad vraagt ​​om verschillende gegevens in verschillende formaten die zijn geoptimaliseerd voor verschillende (vaak schijnbaar willekeurige) factoren.

Geweldige API's zijn voorspelbaar en betrouwbaar. Amerika's Land Use API's worden geplaagd door willekeur. Zodra bouwers voldoen aan de moeilijke API-vereisten, is er geen garantie dat een stad toestemming geeft. Zodra ze gegevens van een bouwer hebben ontvangen, nodigen veel steden letterlijk irrationele tegenstanders van verandering uit en mensen met een direct financieel belang bij het blokkeren van bouwers om de voortgang te onderdrukken. De algoritmen die de kern vormen van Amerikaans landgebruik zijn zo onbetrouwbaar dat ze doelen voor internet satire:

Buitenstaanders begrijpen niet echt hoe raar het planningsproces is.

Stel je voor dat je een meester-timmerman bent. U bouwt al jaren meubels en kasten. Je hebt een stijl die je hebt ontwikkeld en een trouwe klantenkring die dol is op je producten...

- uw lokale zelf toegebrachte huisvestingscrisis ouroboros (@itsahousingtrap) 29 juli 2022

De steden van Amerika zijn een technologie verpakt in een kapotte API.

Hoe het API-probleem van steden op te lossen

De meeste mensen richten zich op politieke of juridische oplossingen voor Amerika's kapotte landgebruik-API's. In zijn boek Landgebruik zonder zonering, professor in de rechten Bernard Siegan stelt dat Amerikanen steden voor het Hooggerechtshof zouden moeten dagen voor hun disfunctioneel landgebruik. Maar zelfs als deze moeilijke juridische verandering zou slagen, zou het steden alleen vertellen wat niet te doen.

Net als bij andere technologieën zijn startups onze beste hoop op innovatie. Startups moeten rechtstreeks concurreren met oude steden om betere landgebruik-API's aan te bieden aan Amerikaanse bouwers. In de praktijk betekent dit dat startups grote stukken land moeten kopen en hele buurten en zelfs steden moeten bouwen.

Het idee dat startups buurten of steden kunnen bouwen klinkt vergezocht, maar het is een oude Amerikaanse traditie. Van spoorwegboomtowns tot Las Vegas, tot grote winkelcentra, tot Walt Disney World, tot de eerste buitenwijken, Amerika's geschiedenis is rijk aan pioniers die onze gebouwde omgeving niet alleen met één enkel gebouw vormden, maar door het bezitten en exploiteren van complexe gemeenschappen . Oprichters, gewapend met de discipline en technologische capaciteit van moderne startups, moeten deze Amerikaanse traditie herontdekken en startup-steden bouwen.

Bovendien is het bouwen van API's voor landgebruik een goede zaak. Het verhaal van Vail Resorts gaat niet alleen over skiën, maar ook over landgebruik controleren nabij mooie skipistes. De Irvine Company gebouwd Irvine, Californië tot 300,000 inwoners door middel van controle over de Land Use API. Howard Hughes Corpo heeft een aantal van Amerika's best beoordeelde en meest winstgevende gemeenschappen gebouwd door grote stukken land te kopen en de Land Use API erin te beheren.

Hoewel software alleen de Amerikaanse steden niet zal repareren, is software wel stroomlijnen van het bouwproces voor startende steden.

Startende steden kunnen bijvoorbeeld een eenvoudige gegevensstandaard maken voor bouwvoorstellen, vergelijkbaar met de Open Graph or JSON-LD standaarden die op internet worden gebruikt. Een dergelijke standaard – die zo simpel zou kunnen zijn als CAD-bestanden met metadata – betekent minder op maat gemaakte Powerpoint-presentaties en duizenden dollars bespaard op advieskosten.

Startende steden kunnen ook softwareworkflows voor bouwers aanbieden die zijn gekoppeld aan echt land. Gelijkwaardig aan Ruimtemaker, Delven, paraffine, or Gezinshulp, kan een startende stad hun favoriete esthetiek en andere kwaliteiten coderen in een machine learning of ander generatief model. Bouwers kunnen parameters aanpassen om bijna oneindige ontwerpen te maken voor hun use-case. Opstartsteden kunnen vooraf vastleggen op automatische goedkeuring voor alles dat door hun software wordt gegenereerd.

Terwijl legacy-steden veel ideeën ronduit verbieden, kunnen startup-steden eenvoudige regels specificeren - vergelijkbaar met op formulieren gebaseerde codes – dat elk gebouw toelaat, zolang het maar onder bepaalde limieten functioneert voor overlast zoals geluiden of geuren. Als een geautomatiseerde fabriek van de toekomst stil en zonder vervuiling kan werken, waarom zouden we die dan uit de stadsgrenzen weren?

De lat ligt in deze branche zo laag dat zelfs basisprincipes zoals doordachte klantenservice belangrijke innovaties zouden zijn. B2B-softwarestartups investeren in Customer Success-teams, die klanten helpen hun technologie te gebruiken. Waarom zouden startende steden geen 'Builder Success Teams' aanbieden, die optreden als conciërge voor degenen die willen bouwen?

Software-startups maken ook publieke toezeggingen over de snelheid en kwaliteit van hun API's. In een wereld waar bouwers worden geconfronteerd met jaren van vertraging en dubbelzinnige tijdlijnen, zou een publieke toezegging om "48 uur of minder" toestemming te geven om te bouwen een radicaal aanbod zijn - de startup-stadsversie van een Service Level Agreement of 'geld-terug-garantie'.

Het grootste verschil tussen legacy-steden en startup-steden is dat startups willen groei. Deze fundamentele verandering in prikkels kan innovatie ontketenen in de software en service die de gebouwde omgeving van Amerika aandrijft.

We kunnen de toekomst niet bouwen als we stoppen met het bouwen van steden. Net als in elke andere branche, gaat het vragen van legacy-bedrijven om het beter te doen niet zo ver. Om de Amerikaanse steden te repareren, moet een nieuwe generatie oprichters startups bouwen die rechtstreeks met hen concurreren.

Geplaatst op 13 september 2022