Building the Thing I Wish I’d Had Before I Bought My First Rental

5 minute read

It’s 11:40pm. Do you know where your polygons are?

It’s 11:40pm on a Friday and I’m staring at a ZIP code boundary that won’t render correctly on a map for the 20th time. The polygon is trying to wrap itself around the entire Eastern seaboard because somewhere in a coordinate system I don’t fully understand, a projection did something a projection should not do. My wife went to bed an hour ago. I am debugging a map.

This is, apparently, how I relax now.

I own two rental properties. I underwrote both of them the old-fashioned way: a spreadsheet, a lot of Zillow tabs, some gut feel, and a healthy dose of “well, it seemed fine.” It worked out. But “it worked out” is not a strategy, and I’ve always wanted something more rigorous — something that forces me to ask the boring, unglamorous questions before I fall in love with a listing photo of a nice kitchen.

So I’m building one. It’s called, very unpoetically, the REW platform (real estate underwriting — I never claimed to be a marketer). And I want to talk about it now, while it’s unfinished, rather than waiting until it’s polished enough to be impressive. Partly because I think the process is more interesting than the finished product. Mostly because I suspect I’m going to get a bunch of this wrong, and I’d rather be honest about that from the start than pretend I built a flawless machine on the first pass.

The Actual Problem I’m Trying to Solve

Here’s the question that matters: out of every possible place I could buy a rental property, how do I quickly rule out the bad ones and spend my real time and energy only on the good ones?

Most people do this backwards. They fall for a specific house, then start justifying the numbers to themselves. I’ve done this. It’s a great way to talk yourself into a mediocre deal because you already mentally moved in.

So I’m trying to build a pipeline that works in the opposite order: start broad, get skeptical fast, and only let a deal survive if it earns its way through several rounds of me actively trying to kill it.

Right now, that pipeline has three stages.

Stage One: Is This ZIP Code Even Worth Looking At?

Before I care about any specific house, I want to know something more fundamental: is this area one where owning a rental makes sense at all?

I built a scoring engine that pulls data from a handful of sources — Census, HUD, FRED — and boils a ZIP code down to six metrics I actually care about as a landlord:

  • Population growth (are people moving here, or leaving?)
  • Unemployment (is the local job base healthy?)
  • Price-to-rent ratio (are prices in line with what rent can support, or wildly detached from it?)
  • Median income (can the local population actually afford the rents I’d need to charge?)
  • Vacancy rate (is there a glut of empty units I’d be competing against?)
  • Supply pipeline (how much new housing is already under construction or permitted nearby?)

That last one took me the longest to get right, mostly because “how much is being built near here” turns out to be a genuinely annoying question to answer with public data. I ended up pulling county-level building permit data from the Census Bureau and matching it up as best I can to individual ZIP codes. It’s not perfect. I know it’s not perfect. But it’s a meaningfully better signal than “I have a feeling about this neighborhood,” which was more or less my prior methodology.

The output of stage one is just a score and a rough read on the market. It’s not a green light to buy anything. It’s closer to deciding whether a neighborhood deserves five more minutes of my attention.

Stage Two: Now Let’s Try to Kill It

This is my favorite part, mostly because it’s the part I was worst at doing manually.

Once a ZIP code clears the first screen, I don’t move straight to a full underwriting model. Instead, I run a quick, deliberately unforgiving pass on the specific property: rough rent estimate, rough expenses, rough financing assumptions, and a gut-check cash flow number. Nothing fancy. The whole point of this stage is speed and skepticism, not precision.

I’m explicitly trying to find a reason to say no. If a property can’t survive a lazy, surface-level version of the math, it has no business surviving the detailed version. This saves me from the trap I fell into with my own properties: spending three hours building a beautiful, detailed model for a deal that a five-minute sanity check would have thrown out immediately.

Think of it as triage. A property that fails here doesn’t get a eulogy. It just doesn’t move to the next room.

Stage Three: Full Underwriting, For the Survivors Only

Only the properties that make it through both filters get the full treatment: a detailed cash flow model, sensitivity around rent and expense assumptions, and eventually — this part isn’t built yet — Monte Carlo simulation across a range of market conditions, so I can see not just “what’s the expected return” but “how bad could this realistically get, and how bad could it get in an unlucky sequence of years.” Longtime readers know I have a soft spot for that kind of analysis; I wrote about the same idea applied to a stock/bond portfolio a while back, and I think the same logic applies just as well to a single rental property.

That full underwriting step is the expensive one, in terms of both my time and the computer’s. Which is exactly why I don’t want to run it on every listing I glance at. The first two stages exist entirely to protect the third one.

Where This Actually Stands Right Now

I want to be honest about the state of things, because I think “in progress” is a more useful thing to model publicly than “finished.”

The ZIP scoring engine works, mostly, though I’m still finding edge cases — ZIP codes that straddle county lines are a special kind of headache I did not anticipate when I started this. The quick-kill screen exists but needs more real-world deals run through it before I trust its instincts. And the full underwriting stage is still mostly aspirational; right now it’s a folder full of half-finished code and a Monte Carlo module I keep meaning to properly hook up.

I’m also in the middle of moving the whole thing off my laptop and onto a little Linux box that lives in my house, partly because I like understanding my own tools end to end, and partly because I’d rather not depend on someone else’s server for something I’m going to trust with real buying decisions. That’s its own rabbit hole, and probably its own post.

None of this is a product yet. It might never be, in the sense of something anyone else uses. But it’s already changing how I think about the two properties I own, and it’s forcing me to write down assumptions I used to just carry around in my head, which is worth something on its own.

Why Bother

I could just keep doing this in a spreadsheet. Plenty of successful investors do exactly that, forever, and do fine.

But I like building things, and I like being forced to be explicit about my reasoning instead of trusting a gut feeling I can’t fully explain even to myself. If I’m going to make real decisions with real money — and eventually, real decisions on behalf of anyone else who ever looks over my shoulder — I want a process I can actually defend, one metric at a time, rather than a vibe.

I’ll keep sharing this as it develops, including the parts that don’t work, the ZIP codes that break my map projections at midnight, and whatever the quick-kill screen gets embarrassingly wrong the first few times I trust it. That feels more honest than waiting until it’s shiny.

A reminder that we’re not licensed financial or investment professionals — just sharing what we’ve learned and how we think about it as we build it. Talk to a qualified advisor before making decisions with real money on the line.

Leave a Reply

Your email address will not be published. Required fields are marked *