Most mixed-use projects get the hardware right and the software wrong. They underperform for reasons the pro forma never captured and the leasing team can’t fix.
I’ve spent twenty-five years working on places that are supposed to feel like somewhere. Some of them do. Most don’t. The difference is a little about architecture. It’s a bit about tenant mix. But it’s really about whether the project was designed, from the beginning, as a system for generating daily life, or whether daily life was assumed to arrive on its own once the buildings were finished.
Developers know the feeling of walking a project a year after opening and realizing something is off. The retail bays are leased. The residential is absorbed. The programming calendar is populated. And yet the place feels thin. Foot traffic dips in the afternoon. The plaza is empty at lunch. The restaurants that were supposed to anchor the evening scene are doing fine on Friday and dying on Tuesday. Nobody can quite say why.
The reason is almost always the same. The project was built as a collection of uses rather than as a continuous experience. The uses work individually. The system between them doesn’t.
What placemaking actually is, when it’s working
The version of placemaking that gives the word a bad name is the one that shows up in the marketing deck: lifestyle photography, a programming line item, maybe a mural. It’s placemaking as marketing. The audience can always tell. And developers are right to be skeptical of it.
The version that changes outcomes is something different. It’s the intentional design of the social and behavioral layer of a project: how people move between uses, what invites them to linger, where they cluster, how strangers become regulars, how regulars become advocates. It’s a discipline with its own tools, its own research base, and its own track record. And it has to be integrated into the project from the earliest design decisions, not sprinkled on at the end.
One distinction I use with development partners is hardware and software. The buildings, the streets, the parking, the systems are the hardware. The programming, the operations, the tenant curation, the sensory details, the management culture are the software. Most projects spend 98% of their budget on hardware and assume software will take care of itself. It won’t. A beautifully designed plaza with no programming strategy is an expensive lawn. A perfect tenant mix in a building that doesn’t invite people to pause is a leasing problem waiting to happen.
A real-world reference point
The clearest example I know is Pearl in San Antonio, where I’ve worked with the development team for twenty years. I’ll go deep on Pearl in a future issue. For now, the relevant data point is the rent roll.
Pearl’s luxury residential leases at roughly double the rate of comparable Class A product in San Antonio. The food and beverage tenants on the ground plane post some of the highest occupancies in the region.
None of that shows up in a rendering. It shows up in the income statement, and it didn’t come from a branding exercise. It came from a fifteen-year accumulation of small decisions made consistently: shaded edges where people could linger without committing to a purchase, movable seating that invited reconfiguration, acoustic niches that made conversation feel private in a public space, porous thresholds between indoor and outdoor rooms, a weekly farmers market that built a Saturday rhythm strong enough to pull people back on weekdays. Those decisions added up to a place where people wanted to be. The rent premium followed.
Conventional capital has a hard time underwriting this in advance. When the next building over from Pearl’s flagship residential went looking for financing, lenders said one rent comp wasn’t enough, even with the comp sitting fifty feet away. That gap, between what the numbers can prove and what the place can produce, is the gap developers have to navigate. The good news is that the numbers do eventually arrive. The pro forma can only borrow against them once they exist.
What this changes for a developer
Three things, practically.
First, it changes when placemaking enters the project. The typical pattern is that a developer engages a placemaking consultant somewhere between schematic design and construction, usually to help with programming strategy or retail positioning. By that point most of the decisions that will determine how the place actually functions have already been locked in. The curb cuts are set. The building setbacks are set. The relationship between the ground floor and the public realm is set. Engaging placemaking expertise at entitlements or early schematic is a different conversation, and it’s usually where the biggest value gets created or lost. And the order in which uses arrive at a project, which goes first and which follows, turns out to matter as much as which uses you ultimately choose.
Second, it changes what gets measured. Most mixed-use projects are evaluated on absorption, rents, and sales per square foot. Those are the right lagging indicators but the wrong leading ones. Projects that end up successful almost always have measurable patterns early: repeat-visit rates, dwell time in public areas, the ratio of local to non-local visitors, the diversity of uses within a given hour of the day. A developer who starts tracking these from month one can course-correct. A developer who waits for the leasing numbers is already two years behind.
Third, it changes who you hire and how. The best placemaking work is done by small specialist practices embedded in larger teams, not by big firms that list placemaking as one of forty service lines. Ask a prospective firm to walk you through a project where placemaking decisions measurably changed the outcome. If they can’t, they’re selling you branding.
The bottom line
The developers building the most resilient mixed-use projects right now, the ones that will hold up as remote work, generational preferences, and retail economics keep shifting, are the ones treating placemaking as a discipline rather than a deliverable. It’s not a category of spend. It’s a way of thinking about the project that affects hundreds of decisions across every phase.
The pro forma doesn’t have a line for it. But the underperformance of the projects that skip it shows up in the pro forma anyway, a year or two late, in the only place developers can’t afford it to show up: the income statement.
This is the first issue of The Visionary Developer, a monthly newsletter for developers, investors, and the teams they work with. If a colleague forwarded this to you, you can subscribe at the top of this page. For longer-form essays and field notes, philmyrick.com.