You can’t learn to ride a bike by reading about it.

It’s a universal principle that nothing can be fully understood through explanation alone.

You can watch all the videos, read all the books, ask dozens of questions, and spend hours talking to people who have done something for years. But until you actually do it, you don’t really know.

I’ve come to believe software belongs on that list as well. 

You can understand what a product does without ever understanding what it’s like to rely on it every day. That difference between explanation and experience is where understanding is born.

Here's what years in preconstruction, and years building technology for it, have taught me about that difference — and why and why that gap is worth paying attention to when choosing who to trust.

The difference between understanding and knowing

I’ve said this line a lot of the years.

“Price is only a barrier to the degree that value hasn’t been experienced yet.”

When someone asks, “How much does it cost?”, they’re not weighing dollars against features; they’re weighing all this uncertainty against the hope of a better outcome.

Questions naturally follow…

Will my team actually use it? Will implementation be painful? Will this really change how we work, or will this become another tool we abandon six months from now?

These are honest attempts to reduce risk before making a decision. The challenge is that some kinds of value simply can’t be appreciated until they become part of your everyday work. 

So, how do you get there?

Systems are intentionally built

On the Proper Precon Podcast, Preston quoted Michael Lefebvre’s Managing Design:

“The system is perfectly designed to get exactly the results we’re getting right now.”

This is the new standard for systemic design in preconstruction. If you want a different outcome than the one you're getting today, the system itself has to be built for that outcome. not adapted around it after the fact. The best ones:

• Reflect how estimators actually think. Scope gaps, assumptions, and judgment calls should be first-class parts of the workflow.
• Are built by people who've defended an estimate, not just studied one. Intentional design comes from having felt the friction yourself, not from a feature request backlog.
• And get easier to trust over time, not harder to work around. A system built for the right outcome should feel more natural the deeper you get into it. If you're building workarounds within the first month, it was designed to solve a different problem than yours.

The spreadsheets, systems, manual handoffs, and institutional knowledge that define our workflows today are there by accident; they are a result of a lot of talented people adapting to the tools they inherited. But over time, they’ve become less intentional.

If we want different outcomes, we have to be willing to rethink the systems that produce them and evolve alongside the people using them.

What “Built With Builders” really means

“It’s comforting talking to a company that knows what we do.”

A customer told me this recently and it's stuck with me because it's a compliment about software, sure — but it’s more about the people who built it.

Like myself, many of my peers at Ediphi came from construction. They lived bid day, defended estimates, worked through scope gaps, and made impossible deadlines. They’ve experienced the same pressure our customers experience every day.

We’ve ridden the same bike.

We didn’t build software because we wanted to build software. We built software because we believed preconstruction deserved a better way to work.

I’ve seen that it changes the style of conversations we have. We don’t have to spend the first half of the meeting learning what preconstruction feels like because we’ve already lived it. We understand the tradeoffs, the constraints, and the friction because we’ve experienced them firsthand. 

Trust begins long before anyone logs into the software.

Experience removes uncertainty

On the Proper Precon Podcast, we talk a lot about trust. Something we find ourselves saying often:

"The number may get you in the room, but the story earns the trust."

The best vendor evaluations don't stop at a pitch. They involve a pilot, a working session on your actual project, or enough hands-on time to see how something behaves inside your real workflow.

The vendors worth trusting are the ones willing to let you replace uncertainty with something you've actually seen work. Once that happens, you don't need to be convinced of anything. You already know.

Some things can be explained. Some things can be understood intellectually. But the most meaningful things are only understood through experience — technology adoption, leadership, and preconstruction all belong on that list.

Experience doesn't just validate understanding. It creates it.

Because in the end, the code is simply the delivery mechanism. The experience is the product.

If any of this resonates, I'd love to hear about it. And if you just want to talk precon, my door's always open — connect with me on LinkedIn.