The Three Hats and the Patience Game: A PropTech Founder Case Study

The first time he pitched me the idea, we were sitting in a coffee shop in Coral Gables. He had a napkin sketch of a dashboard that would track every 1031 exchange in South Florida: who sold, who bought, which brokers were involved, and when the replacement property clock started ticking. He talked fast, hands moving faster. I'd seen that look before, the mix of conviction and caffeine that usually precedes a six-month sprint into chaos.

He wanted me to help him "get it built." I said yes, but not as a contractor. I'd do it as a hybrid: fractional CTO, advisor, and accountability partner. Three hats, one friendship, and a roadmap that would test both.

Phase 1: Foundation

The first artifact we made together was the 26-week roadmap, five phases: Foundation, Discovery, Pilot, Sell, Decide. Each phase had gates, watch-outs, and what I called ADHD-friendly guardrails: visible progress markers, weekly resets, and a rule that no new features could be added without a written hypothesis.

In the Foundation phase, our job wasn't to build. It was to define what "proof" would look like. The roadmap's first page shows it clearly: no code until we can describe the customer in a sentence that would make a broker nod. That took longer than either of us expected.

He had millions of contacts from years in real estate, but no paying customers yet. The temptation was to start coding, "just a quick prototype to show investors." I kept pointing back to the roadmap. Foundation means clarity, not code.

The Three Hats Problem

The Three Hats infographic we drew on a whiteboard one afternoon became our shared language. The CTO hat meant I owned the technical architecture and data discipline. The Advisor hat meant I could challenge assumptions about market timing and fundraising. The Accountability Partner hat meant I could call him out when he drifted.

The trick was remembering which hat I was wearing in any given conversation. When he texted me at midnight with a new feature idea, CTO-me wanted to debate schema design. Advisor-me wanted to ask who the feature was for. Accountability-me wanted to say, "Sleep."

Naming the hat saved the friendship. It also made the work cleaner. When I said, "I'm putting on my Advisor hat," he knew I wasn't rejecting his idea, I was testing it. That small ritual turned potential friction into structure.

Fundraising Is Downstream of Evidence

Midway through Discovery, he started talking about raising money. "If I can show the data pipeline, I can raise a few hundred K." I pulled up the Idea vs. Customers infographic, a simple chart showing how realistic raise size grows roughly 5x between pre-customer and post-pilot stages. The x-axis is evidence; the y-axis is capital. The slope is patience.

I told him, "Investors don't fund potential energy. They fund proof of motion."

That chart became our north star. Every time we hit a decision point (hire a dev, buy a dataset, start outreach) we asked, "Does this create customer evidence?" If not, it waited.

The discipline paid off. By the end of Discovery, we had three brokers willing to pilot. Not paying yet, but engaged enough to give feedback. That's when fundraising conversations started to sound real.

The Working Agreement

Before we started, we wrote a working agreement. Two pages, plain language. It covered equity, off-ramps, and what we called the friendship clause: if either of us felt the work was hurting the friendship, we'd pause before it broke.

That clause turned out to be the most valuable line in the document. It gave us permission to name tension early. When he missed a deliverable or I pushed too hard on scope, we could say, "Friendship clause check-in?" and reset.

The agreement also made equity feel less loaded. We tied vesting to milestones on the roadmap, not time. That kept incentives aligned with progress, not hours logged.

ADHD as Texture, Not Label

He's open about having ADHD, and it shows up in the work: bursts of brilliance followed by context collapse. My job wasn't to fix that; it was to design around it. The roadmap's weekly gates, the visible progress markers, the rule of written hypotheses, all of it came from that need.

The best days were when his energy met structure. He'd surface a pattern in the data I hadn't seen, and I'd translate it into a testable experiment. The worst days were when we both chased novelty. The guardrails kept us from burning the week on tangents.

The Patience Game

By Phase 4 (Sell) we had a working pilot and a handful of brokers using it to track exchanges. The data was messy but real. He wanted to raise immediately. I wanted to finish the Decide phase first: prove retention, not just activation.

That's the patience game. Founders feel time as pressure; consultants feel it as process. The tension is healthy if you can name it. Our roadmap literally ends with a gate labeled Decide: raise, pivot, or sunset. We're not there yet.

What I've learned is that patience isn't passive. It's active restraint, the discipline to let evidence compound before you spend it.

What This Work Teaches

Every consulting engagement teaches you something about yourself. This one reminded me that structure is empathy. The roadmap, the three hats, the friendship clause, they're all ways of protecting momentum without breaking trust.

It also reminded me that early-stage work is emotional labor disguised as product strategy. You're not just building software; you're building belief systems that can survive contact with reality.

If we get to the Decide gate and he chooses to raise, great. If he chooses to pivot, also great. The real win is that we'll still be friends, and the data will be clean enough to make the next decision with eyes open.