When It Isn’t the Market

What causes real estate developments to fail?

When It Isn’t the Market

Antonia Botero is the founder and Adrian Guenther a managing partner at MADDPROJECT, a national real estate development and development-management firm working across resort, hospitality, mixed-use, and residential projects. Together they've delivered more than $1.5 billion in development across 35-plus jurisdictions.

Editor’s Note: Antonia and Adrian will be teaching a workshop, How Developers Keep Control of Cost, Schedule, and Scope, on Tuesday, September 22nd.

Every downturn in real estate gets a villain, and lately it's been interest rates. 

Finance publications have run the story on repeat for the last few years. The Urban Land Institute wrote about it in 2024, S&P Global Market Intelligence a month later, CoStar and American Banker through 2025, and MMG Real Estate Advisors and PBMares into 2026. Almost every month for the past two years, some credible outlet has pinned the recent wave of real estate defaults on rising interest rates.

However, despite the very real effect of rising rates on existing real estate, the idea of outside forces sinking a project frequently gets stretched onto development. Overruns on ground-up work are common, and when they happen, the instinct is to blame the usual suspects like rates, materials, and labor.  Those explanations came up on many distressed projects we took over, but it was almost never the actual cause. The trouble almost always traces back to decisions the team made along the way.

Unfortunately, there is very little published data on how development projects actually perform. Firms don't publish how their projects turn out, investors rarely share returns, and there's no benchmark for how well a developer runs a job. The data we have measures other things. The most-cited construction metrics track planning activity, permits, and future spending, none of which show whether a project was run well. Development performance can only be seen from the inside, which is where most of the experiences in this letter come from. 

Over years of running development projects, we've seen teams make the same small set of mistakes. This letter walks through those mistakes, from the earliest planning through construction:

  • The early decisions that set a budget before construction starts
  • The handoff to construction, where scope and price are confirmed
  • The unglamorous work
  • Why the market takes the blame anyway
  • What this means for developers and their investors

Where budgets go sideways

The decisions that determine a budget are made early. They rarely feel like budget decisions at the time, which is why less experienced teams get them wrong. By the time trouble becomes clear, the decisions that caused it are often far in the past.

Critical early mistakes matter most because no amount of budget or schedule savings later can fix them. A team can run a flawless process and still end up with a loss that was set in motion long before design started. Mistakes in strategy, concept, basis, or the commercial plan are the most unforgiving.

Some of the worst development problems we've seen trace back to strategy. By strategy, I mean concept, schedule, capital structure, and plan to sell or lease the building determined together. Setting those pieces in isolation, or leaving one out at the start, is not a good way to begin a project. It leads to schedules disconnected from the budget, and delivery dates that miss the market. A strategy mistake is the hardest to reverse, because everything that comes after, from concept and entitlement through design and construction, depends on it. Most of the takeovers we've handled started with no strategy.

On one project we consulted on, the building was oversized for what its market could absorb. Initial construction pricing made it clear, but by then, the only fix was to redesign the whole project. The schedule, the financing, and the concept had each been set on their own and looked fine. No one had reconciled them against each other. By the time the team finished the redesign, they had missed the market window for the product, and the project was never built.

After strategy sets the structure, the concept determines who the building is for and what they will pay. No amount of good execution fixes getting the product wrong, and the concept often goes untested until the intended buyers or tenants don't show up. 

Basis works the same way. Overpaying for any of the costs of getting into a deal like land, the entitlement costs, or the financing terms hurts returns. A high basis can't be undone however well the rest of the project goes. Most developers can see the trouble coming, but by the time design is underway and financing is finalized, it's too late to do anything about it. A deal stretched on basis has less room to absorb a rate move or a delay, so a routine slip can become a default.

We most often see avoidably high basis in three specific kinds of deals. One is distressed projects bought out of bankruptcy that were cheaper than before but still too expensive to work. Another is projects where the developer's taste drove the concept, resulting in a building that was more expensive to build and harder to sell. The third is deals where improper entitlement retroactively created a high basis when what was entitled could not support the price paid for the land.

On one multifamily project, the owner overspent by about 25% overall, mostly by feeling strongly about finishes and ignoring every suggestion to pull back. The clearest example was a very particular tile he fell in love with and specified in every guest bathroom, at roughly 40% more than a standard tile. When leasing, agents kept reporting that prospects disliked it, with some asking whether it could be swapped before signing a lease. None of it added value the market would pay for, but the basis went up anyway.

All of this feeds the commercial plan, the piece that ties the physical building to the money it's supposed to make. Commercial plans are often neglected until late, so the team designs to assumptions instead of a finished program and risks building something that can't hit the underwritten returns. Retail and restaurants are the clearest example, since their sales are tied directly to the quality of the physical space, total area, frontage, and seat count, so a program set without those considerations can cap revenue even before the doors open.

On another project we took over, the team properly sized the retail space with its retail partners early, then lost track of it through design. In the push and pull of coordination, the design team didn't protect the program, the developer didn't catch the shift, and the drawings were finalized with a retail floor too small to support the sales the project needed to pencil.

Aside from helping determine the physical aspect of a project, the commercial plan sets much of a project's timing. Lease-up pace and sales absorption have to be set with input from the team running leasing or sales. Getting these assumptions wrong can meaningfully shift the project's returns, and by the time the actual sales pace is clear, there's little the team can do about it.

On one of the first projects we ever took over, the executive team running it had gone nearly a year into design without a defined commercial plan. By the time investors started asking how the building would actually operate, they couldn't answer, and that gap, not the design itself, was what cost them investors’ confidence, and ultimately their jobs.

The handoff to construction

Having a project on a good early trajectory isn't a reason to hand it off to someone else. Yet when it comes to construction, that's exactly what many developers do. The first mistake we see is signing a construction contract without complete drawings. Drawings are never fully ‘done,’ but that reality becomes an excuse for signing contracts on drawings that don’t capture the full scope. That moves the risk from the contractor back to the project. It usually happens because the developer didn't allot enough time for design, which forces a bad choice between designing through construction or delaying the whole schedule.

Signing the contractor's form contract is another common trap. Those agreements don't favor the developer and often skip terms that protect the project when something goes wrong, things like adequate indemnification, a cap on general conditions, and clear language for contemplated delays. After signing the contract, many developers consider their job done and stop showing up, including for buyout, the phase where the general contractor bids the work out to subs. That's a mistake, because buyout is where the team can add the most value during construction. A team present at buyout offers another set of eyes on the bids and can bring in subs and vendors from past projects, where the relationships usually mean better pricing.

Having our own set of eyes on the bids has paid off more than once. On one of our projects, a bid came in with 30% more elevator stops than the building had, and the construction manager missed it. Catching it kept the true low bidder from being thrown out on inaccurate leveling. On another, the apparent low bidder carried an alternate HVAC system that looked cheaper on its own but would have required re-coordinating the whole building, costing more once every other trade was counted. Neither was visible on a leveling spreadsheet, and both would have meant overpaying if the team hadn't been in the room.

The unglamorous work of holding a budget and staying on schedule

Once the work starts, following the budget week by week is the least glamorous work there is. This is the part many developers underestimate, and where experienced teams focus most of their time and attention. Watching the budget means keeping internal accounting beyond what the contractor reports. A full cost breakdown includes the owner's soft costs, design, and financing, and keeping all of it in one place is the only way to know whether a project is on track. Experienced teams also track costs against contract values and ahead of need, so cash flow keeps pace with financing. The contractor's reporting alone leaves the team looking at a partial, slightly old picture, while internal tracking, kept current, shows the budget drifting months before it becomes an overrun, while there's still time to fix it.

Managing payments is where that discipline really pays off. Three mistakes show up on repeat in pay applications: billing that doesn't follow the contract terms, billing ahead of the work, and clerical errors. These cause some of the worst problems we've seen during construction, like running out of funds while work remains outstanding, or the lender stopping funding until the issue is resolved. This is why a detailed review of all payables is one of the most important parts of the job. Paying on time is part of the same discipline. When undisputed payments for finished work get held up, trades do what any business would: pull crews, demobilize, and eventually file liens, all of which push the completion date and add cost along the way.

Accounting hygiene isn’t complicated, but it is tedious, and sustaining it across a whole project takes skill, staff, and money, which is why many developers neglect it.

Why the market takes the blame anyway

These lessons are challenging to study because there's no way to run a development “control group." A developer who makes the right calls never sees the version where they didn't, so a project that took near miracles to finish looks, from the outside, exactly like one that was never in trouble.A developer can't prove a good decision saved a project, and no one can prove the market sank it either, but it's far easier to blame the market. By the time a refinancing or sale puts a real number on the project, the decisions that caused an overrun are hard to trace, while the rate move is recent and widely reported. "Rates increased" is an easier story to tell investors than "we lost track of our own costs."

What this means for developers and their investors

The professionalization that has reached property and asset management hasn't fully reached development, partly because development is much harder to standardize. Plenty of capable sponsors still run the budget on instinct, lean on the contractor's numbers, and treat cost control as something that happens to them. As capital gets more selective and deals get harder to pencil, those habits are becoming a disadvantage, and the developers completing successful projects in a hard market are standing out.

The shift is already underway, and the clearest sign is the software that has been built for development over the last decade. Work that used to live in spreadsheets now has a purpose-built platform at nearly every stage. Acquisition and pipeline teams run deal-management, CRM, and market-data platforms. Feasibility and test-fit studies that once took months now take under a week, since new tools ca generate massing, yield, and parking options against a pro forma. Fundraising and investor reporting run on fund-administration platforms. Cost control is its own category now, with many options built specifically to keep a live anticipated cost report and flag budget variances as they appear. None of this existed at this depth ten years ago, a sign development is professionalizing the way property and asset management already have. But a tool is only as good as the systems behind it. Software organizes a process a team already runs well, and a platform nobody uses is just a cost.

Using these tools doesn't require a large team. Most of what determines a project's success is judgment and attention, not headcount. A lean team with the right processes and outside consultants can manage real size and volume. On small projects, the accounting is simpler and the moving parts fewer, which makes the discipline easier to run. The mistake is assuming a small project doesn't need it, which is exactly how a team loses control of a project that should have been manageable.

For the investors who back these deals, the implication is clear. A developer's grip on strategy, budget, and schedule is not a soft skill. Investors can get a very good indication of how a sponsor will perform from their process, their project management systems, the team running the day-to-day, and the software they use. This is particularly helpful because many sponsors' track record from the last few years can be attributed to the ZIRP era, when it was tough to tell who succeeded on skill and who succeeded because of cheap money.

Going over budget isn't something that happens to a developer. It's the result of choices they made. Very little of a development project's success comes down to the market. Development rewards ownership, and the developers who stay present through the process, from the first decision to the last, are the ones who believe they can control the outcome. Unsurprisingly, many of them do.

-Antonia Botero and Adrian Guenther

Great! You’ve successfully signed up.

Welcome back! You've successfully signed in.

You've successfully subscribed to Thesis Driven.

Success! Check your email for magic link to sign-in.

Success! Your billing info has been updated.

Your billing was not updated.