When Daniel Cannon bought his fixer-upper in Puerto Vallarta, he expected chaos. What he didn’t expect was the psychological déjà vu: the exact same emotional rollercoaster he’s felt during custom software builds, the mismatch between dream and reality, the “oh no” discoveries behind walls and inside code, the scope creep triggered by new shiny ideas halfway through a project, and the uncomfortable truth that the hardest part of any build isn’t the thing you want to build; it’s everything unexpected you discover along the way.
This is the part nobody tells you: Whether it’s code or concrete, everything always takes longer, costs more, and changes more than you think it will. And that’s not failure. That’s the work.
Lesson 1: Fixed Bids Die the Moment Reality Touches Them
Daniel had a dream of a commercial-chef-worthy kitchen. Then he discovered the reality of the Mexican supply chain: certain components literally don’t exist locally. In software? Same thing.
Clients come in with feature fantasies. Until you dig in and realize: the plumbing is wrong. Sometimes literally. Daniel discovered a bathroom in his house that was never even connected to the sewer. In software, this is the equivalent of: “Yeah, so this mission-critical feature you want must sit on top of a data model that is actually broken.”
Fixed bids make people delusional. Fixed bids imply you know the full cost, scope, labor, constraint, decisions, and tradeoffs before you open the walls or open the repo. You don’t.
What works in construction doesn’t work in code: Waterfall is cute for prefab kitchen cabinets. It is a nightmare to build a system for human beings with changing needs, evolving use cases, and shifting priorities. Software is not a four-page marketing website. It’s complex, interdependent, and continually evolving.
Lesson 2: Discovery Should Center on Mission, Not Menu Items
The difference between a disaster build and a good build is not who writes cleaner code or installs prettier tile. The difference is how well aligned everyone is on the mission.
When Daniel’s wife says, “I want two sinks. But I don’t care what the material is,” that’s flexible. That’s gold.
When she says, “The tub must go. That’s non-negotiable.” That’s also gold.
Great discovery isn’t: “Tell me exactly where these buttons go on which screen.”
Great discovery is: “What problem must this fundamentally solve?”
Clients, founders, and homeowners all start by describing solutions. But the real value is clarifying the “have to have” vs. the “would-be-nice.” Focus on mission and outcomes, not shiny UI elements or technical wishlist fantasies.
Lesson 3: The Trust-Building Pattern Is The Whole Game
A consultant, whether a contractor with a hammer or a senior engineer with a text editor, has one job at the start: Earn permission to say no.
Daniel and his wife worked with a small test phase first before committing to the big remodel. They needed proof he wasn’t running up the tab. In software consulting, the same rules: Start small, deliver, build trust, then scale scope.
Lesson 4: Educate Your Client On What You Cannot Know Up Front
There is a reason software has bugs. Not because devs are sloppy, but because literally everything becomes more complex once it hits the real world. There is a reason houses have surprises. Not because contractors are shady, but because you don’t know what’s behind walls until you cut them open.
A bathroom that drains into the garden is the construction equivalent of a legacy codebase that was written by a freelancer who copied and pasted from Stack Overflow eight years ago. You can’t estimate the unknown. The honest way is to explain the nature of unknowns. And normalize iterative decision making.
Lesson 5: Continuous Touchpoints Beat Big Plans
Here’s something contractors and consultants both know: When the client disappears for 3 months and then reappears, everything is worse. Momentum dies, context decays, and the plan you began with is now outdated.
The most underrated discipline is simple: Show weekly progress, even if it’s ugly. Plumbing code looks like nonsense. JSON output looks like gibberish. But those ugly milestones are the real work. Pretty front-end screens are like tile veneer on the side of a skyscraper. They’re the last 5% that make it look done. Don’t get addicted to the veneer.
Final Thoughts
The most useful mental model: Be okay being a little over budget, a little behind schedule, and very happy with the outcome. Whether it’s wall tile or API plumbing, perfection is not the goal. Progress is.
Software isn’t ever done. Houses aren’t truly done either. There’s always the next thing: dimmer switches, new pantry shelving, better reporting dashboards, better caching strategies. Projects evolve. And if you let them evolve with clarity, collaboration, and continuous involvement. You won’t just get a working house or a working app. You’ll get a result that feels like yours. And that’s the entire point.
Daniel’s Background
Daniel Cannon is the Chief Innovation Officer at Delta Systems and Founder and CEO of Strive DB, bringing a wealth of experience in modern web development frameworks and architectures. His expertise spans full-stack development, with particular depth in Ruby on Rails and modern JavaScript frameworks. Daniel's hands-on experience with both traditional and cutting-edge technologies, combined with his ability to evaluate technical trade-offs in practical business contexts, provides valuable insights for organizations navigating technology decisions.
Listen to the new episode on: