Read the essay
III. Structure & Systems · #25 of 75

Architecture models too late.

Who This Matters To (And Why)

Critical: Developer (by the time you hire the architect, the building is largely determined), Architect (you are hired after the most consequential decisions are made — this limits and defines your real scope), Banker (construction loan underwriting happens after design is complete, but the financial model was built months before).

Important: GC (your input early would reduce VE later, but you're rarely brought in early enough), Broker (market data that could inform the program is rarely captured before design begins).

Context: City, Investor, Engineer.

Highest typology impact: Multifamily, Office, Industrial — any project where developer, architect, and GC are separate parties with separate engagement timelines. Lower impact: Design-build and developer-led firms where integration is organizational.

Architecture models too late because the decisions that determine cost, density, and feasibility are made in the pre-design phase by developers, lenders, and market analysts. The architect arrives to execute decisions already made, not to shape them.

How It Shapes Development

The typical multifamily development timeline proceeds as follows: developer identifies a site, conducts a feasibility study, signs a purchase and sale agreement, secures entitlement financing, hires a market analyst, builds a pro forma, negotiates a construction loan term sheet, closes on the land, and then hires an architect. By the time the architect sits down at the kickoff meeting, the unit count, unit mix, approximate construction budget, parking configuration, and financial performance targets are all set. The architect is designing within constraints that were established by others, often months earlier, based on assumptions the architect had no input on.

This is not a complaint. It is a description of how development economics work. The developer has to commit to financial terms before design begins because lenders require it. Lenders require it because they need underwriting certainty. Underwriting certainty requires known program parameters. Known program parameters require market analysis and pro forma modeling. All of this happens before an architect is useful, because it's answering financial questions, not design questions.

The practical consequence is that architects are optimizers within constraints, not originators of constraints. This is fine if the architect understands it and works accordingly. It becomes a problem when architects resist the constraints, insist on reopening program discussions that are financially closed, or treat VE as an attack rather than a consequence of decisions made before they arrived. The architect who enters the project with eyes open — knowing that the unit count, budget, and schedule are not negotiable — can do extraordinary work within those constraints. The architect who enters expecting to shape the fundamental parameters will spend their time frustrated.

The argument for earlier architect involvement is legitimate but has structural limits. Bringing an architect into the feasibility phase can improve program analysis, catch site constraints early, and refine cost assumptions. But the developer's ability to pay for this service before financing is secured is limited. Feasibility-phase architectural work is often done on contingency or at reduced rates, which limits what can be accomplished. The fundamental timing mismatch — financial certainty must precede design depth — is structural, not a failure of communication or professional respect.

Design-build delivery, integrated project delivery, and developer-led architecture firms partially solve this problem by eliminating the engagement sequence. When the same entity is making the financial and design decisions simultaneously, the timing constraint dissolves. Some of the most financially successful residential developers in the US are also their own architects. They make design decisions as financial decisions from the start. The program is the pro forma. This model sacrifices design diversity for financial integration. Whether that tradeoff is worth it depends on the project and the market.

Quick Wins: Connect This Applet To

For Other Professions (24-Hour Builds)