“Cities are technological artifacts,” Kevin Kelly once wrote, “the largest technology we make.” What if we looked at America’s cities not metaphorically as tech, but literally as a technological system?
Rather than fighting about politics, we’d ask our cities the mundane questions that engineers and entrepreneurs ask about any other technology: “Is it expensive to run?” “Does it scale? And especially: “How good are its APIs?”
Cities’ API challenge: land use policy
At its essence, an API (“application programming interface”) describes how users interact with a technology. APIs give structure and set expectations — users know what they’ll get and how to get it.
The core API of the city is its land use policy. Through city councils, planning commissions, and other agencies, city governments provide the API around our built environment. If you want to build in America’s cities, you must integrate with their Land Use API. Today’s Land Use APIs are more paper than digital, but they share a fundamental form with online systems: data in, processing by algorithm, response out. Real estate developers, restaurateurs, and other builders submit data like architectural drawings and environmental reports. The city processes this data and returns a response. Permission to build … or not.
Just as digital APIs structure our experience online, Land Use APIs structure the physical world. They determine what gets built, where, and by whom. Land Use APIs that make it hard to build are behind some of our biggest problems: housing costs, homelessness, and even seemingly unrelated issues like obesity and low birthrates.
How do American cities measure up as technology?
Engineers judge APIs on speed, simplicity, and reliability.
Great APIs are fast. American cities, on the other hand, are notoriously slow to grant permission to build. Requests to these APIs are measured in months, years, or even decades.
Great APIs are simple. America’s Land Use APIs are head-spinningly complex. Even before data hits the API, it must conform to complex specifications of zoning, design, and much more. To comply with the API’s demands, even small projects must spend tens of thousands of dollars to prepare data. Worse still, data isn’t standardized. Each city demands different data in different formats optimized for different (often seemingly arbitrary) factors.
Great APIs are predictable and reliable. America’s Land Use APIs are plagued by randomness. Once builders comply with difficult API requirements, there’s no guarantee that a city will grant permission. Once receiving data from a builder, many cities literally invite irrational opponents of change and people with a direct financial interest in blocking builders to stifle progress. The algorithms at the core of American Land Use are so unreliable that they’re targets for 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 focus on political or legal solutions to 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 for their dysfunctional land use. But even if this difficult legal change succeeded, it would only tell cities what not to do.
As with other technologies, startups are our best hope for innovation. Startups must compete directly with legacy cities to offer better Land Use APIs to America’s builders. In practice, this means startups should buy large tracts of land and build entire neighborhoods and even cities.
The idea that startups could build neighborhoods or cities sounds far-fetched, but it’s 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 rich with pioneers that shaped our built environment not just with a single building, but by owning and operating 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 just 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 create 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 bespoke Powerpoint presentations and thousands of dollars saved on consulting fees.
Startup cities could also offer builders software workflows linked to real land. Similar to SpaceMaker, Delve, Parafin, or Homemaker, a startup city might encode their preferred aesthetics and other qualities into a machine learning or other generative model. Builders can adjust parameters to create 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 specify simple rules – similar to form-based codes – that permits any building as long as it operates below certain limits for nuisances like sounds or smells. If an automated factory of the future can operate silently and without pollution, why should we ban it from city limits?
The bar is so low in this industry that even basics like thoughtful customer service would be major innovations. B2B software startups invest in Customer Success teams, which help customers use their tech. Why shouldn’t startup cities offer “Builder Success Teams,” who act as a concierge for those who want to build?
Software startups also make public commitments about the speed and quality of their APIs. In a world where builders face years of delay and ambiguous 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 biggest difference between legacy cities and startup cities is that startups want growth. This fundamental change in incentives can unleash innovation in the software and service that powers America’s built environment.
We can’t build the future if we stop building cities. Like in any other industry, asking legacy firms to do better will only go so far. To fix America’s cities, a new generation of founders must build startups that directly compete with them.
