“Cities are technological artifacts,” Kevin Kelly once wrote, “the largest technology we make.” What if we treated America’s cities not as a metaphor for tech, but as a technology system, literally?
Instead of arguing over politics, we’d pose the ordinary questions engineers and entrepreneurs ask of every other technology: “Is it costly to operate?” “Does it scale? And especially: “How good are its APIs?”
Cities’ API challenge: land use policy
At bottom, an API (“application programming interface”) explains how users engage with a technology. APIs impose structure and establish expectations — users understand what they’ll receive and how to obtain it.
The city’s central API is its land use policy. Through city councils, planning commissions, and other agencies, city governments supply the API for our built environment. If you want to build in America’s cities, you have to connect with their Land Use API. Today’s Land Use APIs are more paper than digital, but they still follow a basic pattern shared by online systems: data in, algorithmic processing, response out. Real estate developers, restaurateurs, and other builders submit data such as architectural drawings and environmental reports. The city processes that data and sends back a response. Permission to build … or not.
Just as digital APIs shape our online experience, Land Use APIs shape the physical world. They decide what is built, where, and by whom. Land Use APIs that make building difficult are behind some of our largest problems: housing costs, homelessness, and even apparently unrelated issues like obesity and low birthrates.
How do American cities measure up as technology?
Engineers evaluate APIs by speed, simplicity, and reliability.
Great APIs are fast. American cities, by contrast, are famously slow to approve building. Requests to these APIs are measured in months, years, or even decades.
Great APIs are simple. America’s Land Use APIs are bewilderingly complex. Even before data reaches the API, it has to satisfy complicated zoning, design, and other specifications. To meet the API’s requirements, even small projects must spend tens of thousands of dollars preparing data. Worse, the data is not standardized. Every city asks for different data in different formats optimized for different (often seemingly arbitrary) factors.
Great APIs are predictable and reliable. America’s Land Use APIs are riddled with randomness. After builders comply with demanding API requirements, there is no assurance that a city will approve them. Once data arrives from a builder, many cities literally summon irrational opponents of change and people with a direct financial stake in stopping builders to derail progress. The algorithms at the heart of American Land Use are so unreliable that they are the subject of internet satire:
Outsiders don’t really understand just how weird the planning process is. Imagine you’re a master carpenter. You’ve been building furniture and casework for many years. You have a style that you’ve developed, and a loyal customer base that loves your products… — your local self-inflicted housing crisis ouroboros (@itsahousingtrap) July 29, 2022
America’s cities are a technology wrapped in a broken API.
How to fix cities’ API problem
Most people look to political or legal fixes for America’s broken Land Use APIs. In his book Land Use Without Zoning, law professor Bernard Siegan argues that Americans should take cities to the Supreme Court over their dysfunctional land use. But even if this difficult legal change worked, it would only tell cities what not to do.
As with other technologies, startups are our best chance for innovation. Startups must compete head-to-head with legacy cities to provide better Land Use APIs to America’s builders. In practice, that means startups should buy large tracts of land and build entire neighborhoods and even cities.
The notion that startups could build neighborhoods or cities sounds far-fetched, but it is an old American tradition. From railroad boomtowns, to Las Vegas, to town-sized shopping malls, to Walt Disney World, to the first suburbs, America’s history is full of pioneers that shaped our built environment not merely with one building, but by owning and running complex communities. Founders, armed with the discipline and technological capacity of modern startups, must rediscover this American tradition and build startup cities.
Besides, building Land Use APIs is good business. The story of Vail Resorts isn’t only about skiing, but also about controlling land use near beautiful ski slopes. The Irvine Company built Irvine, California to 300,000 residents through control of its Land Use API. Howard Hughes Corp has built some of America’s top-rated and most profitable communities by buying large plots of land and controlling the Land Use API inside it.
Though software alone won’t fix America’s cities, software can streamline the building process for startup cities.
For example, startup cities might develop a simple data standard for building proposals, similar to the Open Graph or JSON-LD standards used across the internet. Such a standard – which could be as simple as CAD files with metadata – means fewer custom Powerpoint presentations and thousands of dollars saved on consulting fees.
Startup cities could also give builders software workflows tied to real land. Similar to SpaceMaker, Delve, Parafin, or Homemaker, a startup city might encode its preferred aesthetics and other qualities into a machine learning or other generative model. Builders can change parameters to produce near-infinite designs for their use-case. Startup cities can pre-commit to automatic approval for anything generated by their software.
While legacy cities ban many ideas outright, startup cities can set simple rules – similar to form-based codes – that allow any building as long as it stays below certain limits for nuisances like sounds or smells. If an automated factory of the future can run silently and without pollution, why should we forbid it from city limits?
The bar is so low in this industry that even basics like thoughtful customer service would count as major innovations. B2B software startups invest in Customer Success teams, which help customers use their tech. Why shouldn’t startup cities provide “Builder Success Teams,” who serve as a concierge for those who want to build?
Software startups also make public promises about the speed and quality of their APIs. In a world where builders face years of delay and unclear timelines, a public commitment to “48 hours or less” for permission to build would be a radical offer – the startup city version of a Service Level Agreement or “money back guarantee.”
The main distinction between legacy cities and startup cities is that startups are driven by growth. This basic shift in incentives can spark innovation in the software and services that support America’s built environment.
We can’t create the future if we stop building cities. As in any other industry, telling legacy firms to improve will only get us so far. To repair America’s cities, a new generation of founders has to build startups that compete with them.