I titled this newsletter “Worth Building” because deciding what is worth building is the bulk of my job. Most, not all, of our projects are funded by private capital. From the private-capital lens, worth isn’t a feeling or a story; it’s based in math — investment return. But no single number captures return, which is the problem. Here are four metrics we use to screen our deals, and each one shows you an angle the others miss. None of them will insulate you from a Black Swan event. Ask anyone who owned a West Coast downtown office tower (or any downtown asset class for that matter) in 2020: no development forecast had a pandemic hollowing it out. What these four can do is measure how much room you have to navigate adverse unknowns — often the difference between crossing the chasm of a down market and not reaching the other side.

Which of the four the market cares about most changes with the capital markets. When money is cheap and growth is assumed, everyone underwrites to the exit and the numbers that reward the dream get the attention. When money is expensive and the future looks uncertain, the market focuses on immediate income and maximum margin. The metric of the moment follows the real estate and capital market cycles. The discipline is to screen all four regardless — because each one guards a different blind spot. We’re wired to build a confident story from the number in front of us; the other three are heuristics that warn against blind spots.

Underneath all four is a single distinction that is critical, particularly for value-add or development projects: trended versus untrended. A trended number grows today’s rents into the future — and sometimes assumes the market will pay a higher price for the same income years out. An untrended number uses today’s rents and today’s prices. That distinction is how you band a deal. More importantly, it distinguishes the real value added of new-construction or value-add projects (more on this below). It’s too easy to feel like a genius when the market is going your way — thinking that the value from your new projects comes from your cunning, rather than simply a rising tide.

Yield on cost is the truth teller. It’s the income the building will throw off once it’s stabilized, divided by what it costs you to build or buy it — real estate’s version of the earnings yield on a stock. Read it untrended, on today’s rents, and it’s the hardest number in the model to argue with. It also ignores the cost of debt, which is exactly why it’s useful. It’s simple and valuable.

Development margin is the moat. It’s the spread between what an asset costs to create and what it’s worth finished, and it’s the investors’ payoff for taking development risk — entitlements, construction, and two years between groundbreaking and the lease-up. It’s also the number most dependent on a cap rate you’re projecting years out (the cap rate is what the market uses to turn a building’s income into a price; a lower one means a higher value), and cap rates are an exogenous market variable, not yours to control. So the honest test strips the projection out: value the finished building at today’s rents and today’s cap rates, against today’s cost. If the margin holds untrended, the moat attributable to development is real. If it only appears with the assumption of compressed cap rates, the moat isn’t the developer’s contribution — it’s market speculation. If you can buy an equivalent building standing for the same money, you’re paying to take construction risk for something you can buy finished. Never pay more to build what you could have bought.

The first two are defensive — they tell you whether a deal is sound. The next two tell you whether you will earn enough to make the investment worthwhile. How you weight each one depends on your investment objectives — including tax sensitivity and time-horizon.

Cash-on-cash is the paycheck. It’s the cash that spins off the investment, divided by the equity you put in. It ignores time-value of money discounts, but provides for actual checks to the bank. This lens comes back into fashion whenever money gets expensive and income gets scarce, and gets a back seat when the market is strong, when capital gain is easier to come by. It’s also the most sensitive to how the deal is financed: leverage and rate structure can dominate it over real estate strategy. It’s the number that matters most to investors living on their dividends — seeking modest but durable returns, not a big figure at the end. And as we’ll see with IRR, it’s also deceptive: a healthy cash-on-cash can be manufactured with leverage that quietly loads the deal with risk.

IRR is the opportunity — and the siren. Internal rate of return is the compounded annual return over the life of the deal. Where the cash-on-cash investor wants to live off the deal, the IRR-focused investor wants to maximize the compound growth rate of their capital over the hold period. It’s one of the truest figures in terms of gauging return, but also the easiest number in the model to inflate. Add debt and the IRR climbs — and so does the risk. A high IRR can mean you found a great deal or that you took a great deal of risk, and the IRR alone won’t tell you which. I read it last, after the untrended numbers have shown whether the deal has enough protective moat to stand market volatility.

This is where Daniel Kahneman’s WYSIATI comes in — what you see is all there is, the trap of judging a deal by a single number in front of you. Humans are bad at pricing risk, so we lean on heuristics; yield on cost is one, because it compares opportunities before leverage amplifies both the returns and the risk.

None of the four is the answer. Each is a lens, and each has a blind spot. Yield on cost tells you whether the building itself, without financing distortions, earns its keep but misses return on equity; cash-on-cash tells you whether you’re paid during the hold but ignores the exit; IRR captures the whole life of the deal but hides how much risk bought that return; the margin tells you whether the building is worth developing at all. Worth, from the capital lens, isn’t any one of them clearing. It’s all four (or at least three, based on your objectives) agreeing — on today’s numbers.

If a deal earns its yield on today’s rents, holds its margin without cap-rate help, provides cashflow while we hold or clears on IRR without leaning too heavily on debt, it’s worth building. If it only works with cap-rate compression and upward-trending rents, better we learn at our desk than on our bank statements.

Worth reading

• The Most Important Thing, Howard Marks — clear writing on risk, emphasizing what you can’t see in the return, but what you assumed to get there.

Get UD+P Market Notes

Alongside Worth Building, I write a quarterly read on the markets we actually underwrite in. Four times a year.

Subscribe → udplp.com/market-notes

My first job out of college was writing software. As a graduate student, I studied information theory and MAP codes — based on theories presented by information theorist Claude Shannon, the eponym for the popular LLM model that I used to code our custom app. It’s no wonder that algorithms behind today’s AI models feel hauntingly familiar 30 years later.

The next decade was spent designing microchips — work in which a single logic error can cost the team a large amount of time and money to fix after fabrication. I enjoyed the rigor and discipline of thinking through problems before you start solving them. I loved the creativity of design work. But it was an unsatisfying profession for someone who likes getting away from the computer and lab bench and getting out into the community.

So, about twenty years ago I moved into real estate development. The technical instincts didn’t disappear, but they went dormant.

Real estate’s roots are not in software or electronics — they are in sticks, bricks, financing and services. So it’s no wonder that the industry software often feels like it was designed by a marriage of engineers and accountants, not a UX designer. Over the years, I would think: there has to be a more efficient way to do this. I would watch an analyst spend two days reconciling a deal package and think, “This should take an hour.” But the gap between seeing a solution and building one was wide enough that I always moved on. Hiring software developers is expensive. Building something real takes time. Running a real estate development firm is more than a full time job.

Recently, the gap between the practitioner, with domain experience, and the engineer, with technical experience, has closed markedly. So much so that I can confidently say the half of my career spent as a practitioner lends more to delivering an effective software solution than my prior years as an engineer (but an engineering mindset is crucial).

What changed

Claude Code is Anthropic’s development tool. It’s more than a code generator. It’s closer to having a software developer who can hold most (importantly, not all) of the context of a system in mind at once.

The quality of the output depends on your ability to describe what to build — employing the skills of a software product manager, like creating a product requirements document. The AI agent builds. You review. You refine. You hit a wall, you refine your approach, sometimes multiple times. Usually it solves it. Occasionally, you need to rearchitect the entire system from scratch and take another swing. We started on a Saturday with one problem in mind — underwriting throughput — and had a working prototype within a couple of weeks. Three coordinating systems were running in production inside a month. A handful of weekend sessions.

However, transitioning that minimum-viable-product into a robust, production-level system took months. Recoding, rearchitecting, refactoring code that had grown into a web. It wasn’t magic and I don’t think I’d describe it as “vibe coding.” One component failed because of a security restriction in the latest macOS — quietly changed, required real diagnosis, required redesigning the approach entirely. The iteration cycle felt familiar — like solving any real-world engineering problem. What changed was how fast each step moved.

Hardening the prototype into production forced a rigor we never needed to apply to a spreadsheet or CRM — securing a multi-tenant system and defending against prompt-injection, where a message tries to smuggle instructions to the AI.

What it revealed

I’ve spent twenty years at the intersection of capital, land, and community. The operational side of the business — tracking, modeling, updating — was always overhead.

Building these tools showed me that I’d underestimated the operational load of our business. Missed follow-ups by the team or long underwriting queues mean lost opportunities.

The tools didn’t change our strategy, but they did reveal how much of our execution was leaking.

Was this worth building?

Yes. Worst case, I became much more adept at using a modern software development tool. With that learning, I have since used Claude Code to develop other functional applications, such as a site-walk app that records photos, videos, and voice & written comments, then uses an LLM to help the user grade the physical condition of a building and populate a database so we have a scoreboard. We’ve prototyped an asset-management dashboard that keeps our forecasts current, organizes our files, and gives us quick access to information like specific commercial lease-terms at the click of a button.

I’m most excited for what this means for the software tools that will be available for our industry. At our company, we hand out socks that have the phrase “no s&*^ty buildings” printed on them to remind us to take pride in what we deliver. I’m excited for our industry to have access to tools that are a joy to use.

Internally, we were able to build software to address inefficiencies that are low-hanging fruit, improve the quality of our work, and, importantly, are easy and pleasant to use. Building beautiful software feels very similar to building beautiful buildings.

I got back something I hadn’t realized I’d missed. And in getting it back, I could see clearly — for the first time — what it had been costing us not to have it. P.S. A few people following this series have asked whether they can use what I built. I’ve started letting a small group of operators in. If you’d like to be one of them, reply — I’ll reach out as I open more spots.

Worth reading

Claude Code documentation, Anthropic. If you’ve read this series and are wondering whether to start: the documentation is more accessible than the technical framing suggests. The question worth sitting with isn’t whether you can build this. It’s whether you’re clear enough about the problem you’re trying to solve.

The File System is the new Database — the first thing I read when I set out to harness Claude; it laid out the progressive-disclosure approach I used to get immediate results, starting with a personal productivity system that grew into the software behind this work.

Compound Engineering by Every.to — the agent-first development method I started from and later adapted to my own workflow; the place to go if you want a concrete system for building with AI rather than just prompting it.

News flash: AI agents aren’t going to take over the world. (Yet, anyway.) Training them — “harnessing” them, in AI lingo — is a lot of work. But the productivity rewards are real. And we need real people to manage them — which, for me, ultimately meant more work and more productivity.

Here’s what that’s actually looked like inside our firm.

The first week after our underwriting agent was running, it miscategorized a line item. Payroll costs mapped to contract services. Not catastrophically wrong — both hit operating expenses — but wrong in a way that would skew NOI by category. We corrected it and noted why. The agent folded the correction in. That particular error hasn’t recurred.

What automation promises

Automation, in the traditional sense, promises a one-time effort in exchange for ongoing removal of work. You build the system, you turn it on, it runs. Rules apply consistently. Inputs produce predictable outputs. That’s valuable — and it’s exactly what breaks when inputs vary, which in real estate they always do. Every seller’s chart of accounts looks different, every operating statement is formatted its own way, and no two rent rolls tell the story the same.

Rule-based systems can’t handle that variation. They hit an edge case and a human takes over.

Agentic AI handles variation differently — through pattern recognition rather than rigid rules. It can do things traditional automation can’t, and it gets better through use rather than just through deployment. The work is in the training, not the build.

What training actually looks like

We have three coordinating agents running now. Each requires a different coaching discipline.

The underwriting agent processes deal documents and maps them to our model. It learns from category corrections — when it maps a line item incorrectly, we note why, and that mapping improves. After each deal, the agent understands our chart of accounts better than it did before.

The investor OS agent extracts intelligence from meeting notes and updates a structured record of each investor relationship. Its training is continuous in a different way — investor preferences change as fund cycles turn. A capital partner who was actively deploying three months ago may be in a quiet period now. The agent learns from those updates as they’re made. Preferences that used to degrade as they sat unrecorded in someone’s head now get captured and updated in real time.

The deal-matching component sits at the intersection of both. When our underwriting system analyzes a new opportunity, it queries our database to surface the most likely capital partners — by check size, geography, strategy, and the contextual signals captured from prior conversations. The quality of that match depends directly on the quality of both upstream systems. Better investor records produce better deal routing. Better deal analysis produces more relevant matches.

These aren’t independent tools. They’re a system. The value compounds in proportion to the consistency of training across all three. We built three narrow agents rather than one general one on purpose: each works within a context small enough to hold completely, and a specialist that fits its problem outperforms a generalist stretched thin across all the problems.

The management discipline this requires

Running these agents is closer to managing a fast-learning analyst than deploying software. The onboarding requires real effort — establishing the structure of your model clearly enough that the agent has something to learn from, coaching early mistakes carefully, building the habit of noting corrections rather than just overriding them.

The payoff is a team member who retains what it learns and applies it to every deal that follows. After three months of deal-by-deal correction cycles, the agent’s output is materially better than it was at launch. Not because the software updated. Because we coached it.

What an agent doesn’t have is a low tolerance for repetition. People get bored, and rightly so — boredom is what pushes us toward the creative, judgment-laden parts of the work where we can add the most value. The agent’s patience for the repetitive parts complements that; it doesn’t replace it.

What doesn’t change

The agent reflects the quality of its manager. What we correct, it learns from. What we overlook — a miscategorization we don’t catch, an LP preference we don’t update — it incorporates as fact. Judgment about what the system should optimize for still comes from the people running it. So does the decision about when the output is trustworthy enough to act on.

A firm that engages with these tools the way it would engage a new team member will find something that compounds. After a year of that, you have a colleague who knows your business — and a team whose attention is freed for the work only people can do.

That’s the trade I didn’t expect when we started. More work, not less. But the work is the kind worth doing.

Next: what the build process actually looked like — and what we’d say to a firm that hasn’t started yet.

We had a CRM. We paid for it monthly. It was frequently out of date.

This isn’t a knock on the tool — we’ve used several over the years and the problem is consistent across all of them. CRMs require input. Someone has to log the call, update the stage, note that a capital partner mentioned they’re not deploying outside the Mountain West this cycle, or that their fund is in a quiet period, or that they’ve been watching a specific market for three years and would move quickly on the right deal. That input requires discipline. Discipline compounds into friction at the end of a busy day, after a call that ran long, before the next meeting. Six months later the database that was supposed to give you a clear picture of your investor relationships is a patchwork of stale entries and missing conversations. With outdated data, we lose confidence in what it tells us.

The problem isn’t the software. It’s the input model.

What we built

We use Granola to automatically capture meeting notes. We built a layer on top of it — using Claude Code — that runs after every investor meeting without anyone doing anything.

It reads the notes, identifies which capital partners were present, extracts the relevant intelligence — investment preferences, check size ranges, geographies of interest, fund timing, anything substantive that came up — and updates a structured record automatically. By the time Preston gets to his desk the next morning, the log is current. No manual entry. No discipline required. The database stays current because the input problem is eliminated, not managed.

What a CRM field can’t hold

Our prior CRM did store information — contact records, deal history, and basic preferences. What it couldn’t store was the nuance of a conversation. And even when someone took the time to write a detailed note, you couldn’t query it. You could retrieve it if you already knew to look. You couldn’t ask: which of our investors has mentioned an openness to development plays in markets they know well, and whose fund timing suggests they’re ready to deploy? That kind of question requires language understanding across unstructured data — which is exactly what large language models are built for.

The agent captures conversational texture in narrative form. It’s searchable, it doesn’t deteriorate, and it doesn’t leave.

Where it connects to deal execution

When our underwriting system analyzes a new deal, it queries the investor database and surfaces the most likely capital partners for that specific opportunity — by equity check size, geography, strategy, and the contextual signals captured from prior conversations.

The result is a prioritized shortlist based on everything we know about each relationship.

The same infrastructure, a different problem

The same tools that enabled the underwriting agent enabled this one. Granola provides summarized meeting notes. The Model Context Protocol connects the agent to our contact database. Claude Code handled the build. Training this agent was faster — it already had a working model for what knowledge matters and how to apply it.

What’s different about this agent is that the coaching is continuous. Investor preferences change. Fund cycles turn. The agent learns from corrections as relationships evolve, which is what keeps the database genuinely current rather than accurate at launch and stale six months later.

What doesn’t change

The agent only surfaces who to call.

We are the trusted partner in these relationships — and trusted partners are built through years of communication, transparency about outcomes, and ultimately delivery on execution. The intelligence the system provides is preparation. The relationship, and the obligation to perform, is ours. What changes is how prepared we are when we pick up the phone.

Next: what the process of actually building all of this looked like — and what we’d tell a firm evaluating whether to start.

Preston, our acquisitions lead, prompted me to look into AI. He knows my background — I spent a decade as a design engineer before moving into real estate — and he probably wondered why I wasn’t already pursuing these tools more proactively. Fair point.

The problem

The problem we were trying to solve was underwriting throughput. Specifically, every deal maps to our model a little differently. The seller’s chart of accounts is never the same twice. Their rent roll format, how they treat one-time items, whether payroll is one line or four — all of it varies. That variability is exactly what makes traditional automation fail. Macros and templates work when the input is consistent. Real estate deals aren’t. I had tried rule-based approaches before and hit the same wall every time: the moment a deal came in with an unfamiliar structure, the automation broke and a human had to take over.

What agentic AI changes is the ability to handle that variability through pattern recognition rather than rigid rules. More importantly, an agent can be trained on your specific workflow and learns from mistakes as you coach it. When it maps a category incorrectly, you correct it. It usually doesn’t make that mistake again.

The initial work was building that learning environment — establishing the structure of our model clearly enough that the agent had something to learn from. That setup takes real effort. But once it exists, training becomes iterative: run a deal through, review the output, correct what is wrong, run another. Each round the agent performs better. The improvement compounds in a way that is genuinely similar to onboarding a junior analyst — steady growth that accelerates once the foundational understanding is in place.

What we built

We built an agent — using Claude Code — that ingests the full document set for a deal: offering memorandum, operating statement, rent roll. It loads and reconciles the data across those sources, translates the seller’s chart of accounts to ours, and runs the same reconciliation process on the rent roll — normalizing unit types, flagging vacancy inconsistencies, identifying loss-to-lease. Each source is cross-checked against the others. Discrepancies get flagged before they reach the model.

That’s not simple work. It requires holding the full picture in context simultaneously — which is exactly what large context windows now make possible, and exactly what breaks under deadline pressure when done manually.

On a recent 150-unit value-add deal, the agent caught three material issues on the first pass: an occupancy history that didn’t reconcile with the rent roll, a one-time insurance recovery buried in operating income, and stabilized NOI overstated by approximately 18% in the seller’s underwriting. What would have taken the better part of two days took about 20 minutes.

Why this wasn’t possible 18 months ago

I looked at this problem in 2023. The tools weren’t there.

What changed: in March 2024, context windows expanded to 200,000 tokens — enough to hold an entire property package in a single pass. In November 2024, Anthropic released the Model Context Protocol, a standard that lets AI agents connect reliably to external files, databases, and systems without fragile custom code. In February 2025, Claude Code made it practical for a firm without a software development team to build and deploy working agent systems. We built ours over a handful of weekends. It’s in production, processing real deals.

More recently, advances in agentic capabilities — reliable tool use, skills orchestration, the ability to hand off between tasks without losing state — put the remaining pieces in place. The context window got us in the room. The agent architecture made it work.

What doesn’t change

The agent doesn’t replace an analyst. It changes what the analyst does.

Someone still needs to manage it — running deals through, reviewing outputs, catching errors, continuing to coach it when something is mapped incorrectly. That oversight isn’t optional. The agent’s reliability is a direct product of the attention given to training and quality control.

What it handles is the data work: loading, reconciling across sources, translating, flagging. What it doesn’t handle is what to do with what the numbers reveal. Market judgment, broker relationships, the read on a seller’s motivation — none of that changes. What changes is that the analyst who previously spent hours on data reconciliation now applies that time to the work that actually requires them.

Next: how the same infrastructure problem shows up on the investor relations side, and what we built to solve it there.

What I found in real estate is that a project’s feasibility tells you what you can build. It doesn’t tell you what’s worth building. The decisions that shape neighborhoods are informed by context, community, and the history of the places in which our buildings are built — not just capital. Getting the numbers right is necessary. It isn’t the whole question.

The question I’ve been asking since — in different forms, across different problems — is: what is actually worth building?

That question is the premise of this newsletter.

I co-founded Urban Development + Partners in 2006. Since then we’ve developed and acquired urban mixed-use projects across Oregon and Northern California — multifamily, office, hospitality, adaptive reuse — and managed investments through the 2008 crisis, the 2020 dislocation, and the post-pandemic office collapse. We’ve made money, lost money once, and written about both with equal specificity in our investor letters.

We’ve also built intentional cohousing communities from the ground up — working with families and baby boomers who want to live differently than conventional housing allows, and with our friend and colleague Katie McCamant, whose work introduced this model to North America.

This year, I built AI agent systems that now run core workflows at our firm — using tools that didn’t exist 18 months prior. I hadn’t written production code in 20 years. That surprised me about as much as it surprised the people I work with.

Worth Building covers the terrain where all of this intersects.

Housing and supply. Why the shortage persists despite broad consensus that it shouldn’t. What development economics look like from the inside. What policies move the needle and which ones just sound good.

Community by design. What communities should we be creating, and how do we build them deliberately? Cohousing for families and for people planning the next chapter. What it takes to develop a neighborhood for people who don’t yet know each other. Why intentional community works, and why most Americans have never heard of it.

Capital and conviction. The investor’s lens on real estate — acquisition strategy, market cycles, fund structure, the hold/sell decision under pressure. The same transparency I use in our investor letters, applied to questions that don’t require a fund subscription to find interesting.

AI and the built environment. Not AI as concept or hype. What we actually built, how it works, what it changed, and what it didn’t. Practical and specific — written by someone still building.

These aren’t unrelated topics. They’re different angles on the same question.

What housing is worth building? What communities should we be helping create? What investments are worth the conviction they require? What tools are worth the time it takes to build them?

Worth Building comes out monthly. Each issue takes one question, one problem, or one idea and develops it fully — no listicles, no predictions, no five tips. A practitioner’s view from the middle of it.

If that’s useful to you, subscribe. If you know someone for whom it would be, forward this to them.