I've spent 17 years building rental income. Now my team and I have launched three mobile apps. None of this was a pivot away from real estate. It was the realization that cash-flowing assets follow the same framework regardless of whether the asset is a duplex or a piece of software.
I want to walk through that thinking. Why a real estate investor has a real advantage when it comes to building software products. What it actually looks like in practice (with numbers from one of our apps). And the honest hard parts that nobody mentions when they're selling you on the idea.
This isn't a "sell your rentals and go build a SaaS" article. It's the article I wish someone had handed me three years ago when I was sitting on a portfolio I'd already built and looking around for what came next.
The shift in how I see assets
Here's the framing that changed things for me.
A rental property is an asset that produces cash flow. You put capital and time into building it (or buying it). You put systems in place to run it. Then it pays you, every month, whether you're at your desk or not.
That's the whole job description of any good asset. Build it once, put systems in place, get paid over and over.
When I started thinking about software products with that lens, I stopped seeing them as "tech startups" and started seeing them as a different class of cash-flowing asset with a much lower barrier to entry than a duplex.
The difference is striking when you look at the numbers.
A rental: tens of thousands or hundreds of thousands of dollars to acquire. Tenants. Maintenance. Vacancy risk. A 7 to 12 percent cash-on-cash yield in a good market. Years to compound into real wealth.
A software product: a few hundred to a few thousand dollars to build. No tenants. No maintenance calls (in the traditional sense). 80 to 90 percent margins after launch. Can compound much faster because the unit economics are radically different.
Both are cash-flowing assets. Both work whether you're paying attention or not, once they're built right. The framework is the same.
The receipt
I'll skip the theory and show you what one of our apps looks like.
We built REPS Time, an app that helps real estate investors track the hours they need to qualify for Real Estate Professional Status. If you're claiming REPS on your taxes, you need documentation that holds up under audit. The app does that.
Build cost: under $300.
Current revenue: five figures every single month.
Marketing budget: zero. No ads. No lead lists. No sales team.
People find it because they have a real problem (qualifying for REPS), they search for a solution, the app comes up, they download it. Same way someone finds a rental listing they want to lease. Same way they decide to fill out an application.
That's not a side project. That's a cash-flowing asset that paid back its build cost in the first month and every month after that has been pure margin.
We've now launched two more in the same vein. Kids Payroll, for business-owner parents who pay their kids to work in the business and need a clean compliance trail. STR Hours, for short-term rental owners tracking material participation hours. Same framework, three different problems we've personally lived through.
The headline lesson: every problem you've personally solved as a real estate investor is potentially a product. Most investors are sitting on three to five of these and don't see them.
Why a real estate investor has the unfair advantage
If you've built a rental portfolio, you've already developed the four mental skills that matter most for building cash-flowing software. You just don't think about them in this context.
You think in cash flow, not in valuations. Most first-time SaaS founders chase user growth and ignore unit economics until they're hemorrhaging money. You don't have that bias. You instinctively ask "what does this actually pay per month and what's my cost basis." You'll build profitable apps from day one because you don't know how to think any other way.
You think in ROI. When you look at a rental, you're not asking "is this cool." You're asking "what's the return on the capital I'm about to deploy." You'll apply that same filter to a feature decision, a marketing spend, a hire. That filter is rare in software founders. Most are emotionally attached to their product. You'll be ruthlessly attached to the cash flow.
You think in systems that work without you. Every rental property is an exercise in building a system that runs while you do other things. Inquiries get screened. Tenants get placed. Rent gets collected. Maintenance gets routed. You've already practiced the discipline of writing the SOP, training the operator, removing yourself from the workflow, the same muscle I used when I replaced two property managers with one remote hire. That same discipline is what separates a SaaS that scales from one that drowns the founder in support tickets.
You're already comfortable with borrowed capital. Real estate investors borrow money to amplify their returns. Software is just a different kind of amplification: code that gets written once and serves a thousand customers. If you're someone who'll happily put 25 percent down on a $400,000 building because the math works, you're going to be very comfortable with the math of "spend $300, build the app, sell it forever."
The combination of those four skills is rare and valuable. Most software founders develop them slowly and painfully. You already have them.
The framework that actually works
I've launched a few different businesses over the years (some of them embarrassing failures, including a brick-and-mortar that cost me five figures and six months in 2011). The framework I use now to launch a profitable cash-flowing software product is five steps. It works for SaaS, for paid communities, for productized services, for almost any digital asset.
Step 1: Find a real problem you've personally solved.
Look at the last five years of your life and find a problem you solved in one of three categories: health, wealth, or relationships. Be specific. Don't pick "I want to help people invest in real estate." Pick "I needed a way to log REPS hours that would actually hold up under audit and the existing tools were spreadsheets that were terrible."
Specificity is everything. The narrower the problem, the easier it is to build the right thing for the right person.
Step 2: Draw your genius model.
This is the blueprint that takes your customer from point A (stuck) to point B (problem solved). Three strategies. Nine actionable steps. That's it.
For REPS Time, the model was: log every billable activity (strategy 1), categorize it correctly per the IRS rules (strategy 2), produce an audit-ready report on demand (strategy 3). Nine steps inside that. Done.
Most founders skip this and start coding. That's why most products fail. The model is the product. The code is just the implementation.
Step 3: Pick a customer avatar that is essentially you, five years ago.
Who urgently needs this problem solved? Who's willing to pay to solve it? Where do they hang out? What do they fear? What do they want?
If your honest answer is "me, five years ago," that's perfect. You'll know exactly what they need because you've lived it. You'll know exactly where to find them because you used to be one of them.
Step 4: Build the offer.
You can package the same solution at three price tiers: do-it-yourself (cheapest), done-with-you (middle), done-for-you (premium). Most investors should start with DIY (an app, a course, a book, a template). It scales. It doesn't trap you in service work. The margins are 80 percent or better.
Step 5: Launch the MVP in 30 days or less.
The instinct is to perfect it. Don't. Get it in front of five beta customers as fast as possible. Collect testimonials. Ask for referrals. Host a free training and pitch your solution. Then iterate based on what real users tell you, not what you imagine they want.
Experiments are more important than perfection. A real product in real customers' hands beats a perfect product in your head every single day.
What nobody tells you
Here's the part that doesn't get said in most "build a SaaS" content.
Distribution is harder than the build. I've spent months refining a product to launch it to a slow trickle of downloads. Then I responded to one Facebook post in a group full of investors with the same problem the app solves, didn't pitch, just answered the question and mentioned the tool, and downloads took off and haven't slowed down.
That single comment did more for that product than months of build work. The lesson isn't that marketing is everything. The lesson is that you have to deliberately put your product in front of the people who already need it. You can't just build it and assume Google will route them to you.
The first six months are slow even when the product is good. This is the part that crushes most founders. They build, they launch, they expect a hockey stick, they get a flat line for a few months, and they quit. The math says you should expect months of "is this even working" before the compounding starts. If you're allergic to that period, software is going to disappoint you the same way new construction will (the first 12 months of a build also feel like nothing is happening).
Your tech stack is now a third of what it used to cost. I recently went through an old invoice from a tool I was paying $2,500 a month for. Today I'd build that same workflow with free or near-free AI tools and pay almost nothing. If you tried building a software product five years ago and the tooling was prohibitive, the math is dramatically different now. The barrier to entry is the lowest it's ever been.
The unsexy operations work matters here too. Customer support. App store reviews. Payment processing. Refund policies. Email replies. The boring stuff is the moat. Most founders ignore it. The ones who don't compound.
What this doesn't work for
I'm not saying every real estate investor should drop everything and build apps. Here's where it doesn't work.
You don't have a problem you've personally solved. If you can't think of one, this isn't the right move yet. Live more, solve more, then come back. The product has to come from a real lived experience or it'll be generic and won't sell.
You hate technology. You don't have to be a coder. You do have to be willing to learn the basic workflow of building, shipping, supporting, and iterating a digital product. If the idea of doing that makes you tired, your time is better spent buying another rental.
You need money next quarter. A new product takes 6 to 18 months to start producing meaningful cash flow. If your portfolio isn't already cash-flowing enough to give you the runway, you're better served buying a stabilized rental than starting a software project.
You're a perfectionist who can't ship. This is the killer. Software gets better through real customers using it. If you're going to keep iterating in private until it's "ready," it'll never be ready. The investors who succeed at this are the ones who can tolerate shipping something embarrassing and improving it in public.
The question worth asking
When I look at the next decade of building wealth, I think the investors who do best aren't the ones who pick rentals or apps. They're the ones who build a portfolio of cash-flowing assets across both classes, because the framework is the same and the diversification protects them when one cycle turns against the other. It's the same monthly-recurring-revenue thinking behind building a rental portfolio in five hours a week, just pointed at a different asset.
Real estate had a great run. It still does. But the unit economics of software are too good to ignore, and the skills you've already developed as an investor are exactly the skills that make a software founder successful.
The question worth sitting with isn't "should I build an app." It's "what problems have I already solved that other people would pay me to solve for them?"
If you can answer that question with even one specific example, you're closer to a cash-flowing software asset than most software founders ever get. They have to invent the problem. You've already lived it.
The next thing you build doesn't have to be a property.
