Buildable {ish}

Brian and Alex

A smart, funny podcast cohosted by a structural engineer and a project manager – two professionals who live day-to-day in construction coordination. We take a candid, smart, and often humorous look at what really happens between design intent and finished construction. Each episode breaks down a common project challenge; misaligned specs, missing details, inspection surprises, field fixes, and the infamous “that wasn’t on the drawings” moment. Keywords: Buildable, Buildableish, Buildable ish, Build, Buildable(ish), Buildable (ish)

  1. 20 hr ago ·  Bonus

    The Spec Trap: One Spec, Two Specs, Old Specs, Blue Specs

    The Spec Trap: One Spec, Two Specs, Old Specs, Blue Specs Show Description Specifications are supposed to clarify the drawings. Until one section references an old code, another came from a different master spec, the owner added their own requirements, the manufacturer says something completely different, and nobody remembers who edited what. In this episode of The Spec Trap, Brian and Alex dig into how a project manual slowly becomes its own coordination meeting. Master specifications, owner standards, manufacturerrequirements, consultant edits, legacy language, and years of revisions can all end up living in the same document, whether they agree with each other or not. The result? Conflicting code editions, contradictory trade responsibilities, outdated products, drawings that don’t match the specs, RFIs, inconsistent pricing, delays, and change orders. Because sometimes the biggest coordination problem on the project isn’t between the disciplines. It’s between the specs. Leave feedback for Biran and Alex brian@buildableish.com⁠⁠⁠ Links Website – ⁠⁠www.buildableish.com⁠⁠LinkedIn – Buildable(ish)Instagram – Buildable(ish)X – @BuildableishShow Notes How Did We Get Here? Specifications evolve over years — and sometimes decades.Master specs get edited, copied, updated, and edited again.Owner standards add another layer of requirements.Manufacturer language gets inserted into project specifications.Consultant edits and project-specific requirements pile on top.Eventually, nobody is completely sure where some language came from. When the Specs Start Fighting Each Other Different sections reference different code editions.One specification assigns work to one trade while another assigns it somewhere else.Drawings and specifications describe different requirements.Products remain specified long after they have changed or disappeared.Requirements survive because nobody realized they were still there.The project manual becomes its own coordination exercise. Why It Matters Contractors price different interpretations of the same documents.Conflicts become RFIs during construction.Outdated requirements create procurement problems.Contradictions become change-order arguments.Small specification inconsistencies can create surprisingly large field problems. Staying Out of the Trap Treat specifications as living documents — not automatically correct documents.Review specifications with the same attention given to drawings.Coordinate specs, drawings, schedules, and details.Check referenced codes and standards.Question language that looks inherited rather than intentional.Ask questions while the answer is still cheap. Takeaways A specification is only as current as its last meaningful review.Master specs are starting points, not finished project documents.Owner standards, manufacturer requirements, codes, and consultant edits all have to be coordinated.Drawings and specifications should complement each other, not compete with each other.A five-minute review during design can prevent a five-day delay during construction.When one spec says one thing, another says something else, and the drawings split the difference — you’ve walked into The Spec Trap. This episode is part of The Spec Trap series — short dives into spec language that sounds professional but quietly causes problems in the field.

    The Spec Trap: One Spec, Two Specs, Old Specs, Blue Specs
  2. 6 days ago

    That Was Not Our Sub

    Episode 013 – That Was Not Our Sub Show Description Everyone thought it was covered. That was the problem. Brian and Alex dive into the increasingly complicated world of subcontractors, sub-subs, delegated scope, and the dangerous assumption that responsibility automatically travels downstream with the work. After a utility survey performed by a consultant’s subcontractor misses a major water line, a renovation projectquickly shifts from teamwork to damage control—and eventually to the inevitable question: Who’s paying for this? From buried scope limitations and five-page incident timelines to steel fabrication mistakes, “not in contract”notes, and subcontractors several layers removed from the original design intent, they explore what happens when everyone performs their individual scope correctly, but nobody owns the outcome. Because subcontracting can move the work. It can move the contract. But it doesn’t automatically move the responsibility. If you’ve ever heard “we hired someone for that,” “that wasn’t our guy,” or the infamous “don’t worry, we’ve got it covered”…this episode is for you. Links & Contact Website – ⁠www.buildableish.com⁠Email – ⁠brian@buildableish.com⁠LinkedIn – Buildable(ish)Instagram – Buildable(ish)X – @Buildableish Show Notes Chapter 1 – The Fine Print Does the Work When a technically correct deliverable still isn’t what the project actually needed.Why scope limitations buried in reports and contracts matter.Treating consultant reports as inputs instead of unquestioned green lights.How assumptions become project facts simply because nobody asks the next question.Why “a professional handled it” is not the same thing as verification.Chapter 2 – That Was Someone Else’s Sub What happens when excavation finds the utility the survey didn’t.The difference between responding to the problem and deciding who pays for it.How multiple layers of subcontracting blur accountability.Why everyone can be correct within their individual scope while the overall project is still wrong.Steel detailing, fabrication, erection, and the cumulative effect of seemingly small tolerances and mistakes.The story of an entire steel frame drilled with the wrong-size bolt holes.Chapter 3 – Liability Finds the Gap Why responsibility becomes harder to identify after the work has already started.Scope defining tasks without necessarily defining ownership of the outcome.Why “Not in Contract” doesn’t always eliminate responsibility.Shared responsibility where one subcontractor’s work interfaces with another’s.How liability tends to land at the weakest handoff.When collaboration turns into paper trails, timelines, and finger-pointing.Chapter 4 – Own the Outcome Delegating work does not automatically delegate responsibility.Why verification is part of design—not just a field courtesy.Keeping centralized awareness even when work is subcontracted several layers deep.Making sure scope limitations travel downstream with the work.Assigning responsibility before construction instead of reconstructing it afterward.Breaking down vague phrases like “by others” into actual ownership of delivery, installation, support, coordination, and final performance.Key Takeaways Subcontracting transfers work, but responsibility for the project outcome still has to be explicitly assigned.A technically correct report can still be inadequate for the decision being made from it.Scope limitations are useless if they never make it into the planning conversation.“Not in our scope” does not necessarily mean “not our responsibility.”If nobody can clearly identify who owns an outcome before construction starts, liability will eventually identify someone afterward.

    That Was Not Our Sub
  3. 12 Aug ·  Bonus

    Scope Gap: Expansion Joints

    Show Description It might be the most expensive line on the drawings. Structure sees movement. Architecture sees a cover. Mechanical sees ductwork and piping. Electrical seesconduit. Roofing sees waterproofing. Fire protection sees a rated assembly. The contractor sees six trades trying to cross the same line. The expansion joint itself usually isn't the problem. The problem is that everybody touches it—and nobody owns the whole thing. In this Scope Gap minisode, Brian and Alex follow the expansion joint through the building and explore whathappens when structural movement meets walls, floors, ceilings, roofing, waterproofing, fire barriers, ductwork, piping, conduit, and finishes. Along the way, they sort through expansion joints, control joints, construction joints, isolation joints, building separation joints, and seismic joints—andwhy using the wrong terminology can create the wrong assumptions. Because the building is going to move. The question is whether everything crossing that line is ready to move with it.   Leave feedback for Brian and Alex ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠brian@buildableish.com⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠   LINKS: Website: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://buildableish.com/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Instagram: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.instagram.com/buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ X: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://x.com/Buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ LinkedIn: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/company/buildable-ish/⁠⁠⁠ Show Notes The expansion joint assumes: Everyone understands what kind of joint it is.The required movement has been clearly defined.Every discipline knows how its system crosses the joint.Architectural covers, waterproofing, and fire barriers accommodate the movement.Somebody coordinated the whole thing. In practice, it becomes: A line every discipline interprets differently.A coordination problem nobody completely owns.A collection of rigid systems crossing something specifically designed to move.A waterproofing, fire-rating, or finish problem waiting to happen. Takeaways: Define the joint type and required movement early.Don't use “expansion joint” as a catch-all for every joint in the building.Coordinate every system that crosses the joint—not just the structure.Make sure architectural finishes, MEP systems, roofing, waterproofing, and fire-rated assemblies can accommodate the required movement.Don't assume another discipline understands the movement criteria.If everybody touches the joint, somebody still needs to own the coordination. “The joint itself is actually not the problem. The question is whether the project team worked.” This episode is part of our Scope Gap series – short dives into the spaces between disciplines, responsibilities, and assumptions where construction problems love to hide. Leave feedback for Brian and Alexbrian@buildableish.com Follow us onLinkedIn – Buildable{ish}Instagram – Buildable{ish}X – @Buildable{ish}

    Scope Gap: Expansion Joints
  4. 5 Aug

    It Fit Yesterday

    "It fit yesterday." Few phrases strike more fear into a design professional than those three words. Brian and Alex dive into the world of structural steel renovations, where existing conditions, undocumented field decisions, and seemingly harmless assumptions can snowball into expensive construction failures. From out-of-plumb columns and crooked masonry walls to reused joist pockets, missing bearing plates, and geometry that was never verified, they explore why renovation projects don't usually fail because of bad engineering—they fail because reality doesn't match the assumptions. If you've ever relied on record drawings, heard "we've always done it this way," or discovered that one small field decision created weeks of downstream redesign... this episode is for you. Leave feedback for Brian and Alex ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠brian@buildableish.com⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠   LINKS: Website: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://buildableish.com/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Instagram: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.instagram.com/buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ X: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://x.com/Buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ LinkedIn: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/company/buildable-ish/⁠⁠⁠ Show Notes: Chapter 1 – When Assumptions Become Facts Why renovation projects rarely begin with completeinformation.The hidden danger of trusting record drawings.Existing conditions that were never actually verified.Why "it worked before" may be the mostdangerous assumption on a project.How geometry quietly becomes everyone's acceptedtruth.Chapter 2 – Steel Doesn't Fail Calculations Coordinating joists, ductwork, and structural framing.Why one misplaced opening can affect an entirestructural system.The hidden complexity of modifying steel already inplace.Camber, reinforcement, point loads, and why smallchanges aren't always small. Chapter 3 – Convenience Rewrites the Drawings Reusing existing joist pockets instead of followingapproved shop drawings.The mystery of the "extra joist."How one undocumented field decision creates cascadingcoordination problems.Why schedule pressure often defeats good engineeringjudgment.The dangerous assumption that "someone must haveapproved it." Chapter 4 – Verify Before You Build Assigning responsibility for verifying existingconditions.Making field verification explicit instead of implied.When an RFI is the fastest path—not the slowest.Why documentation protects everyone on the project.Lessons every renovation project should carry forward. Key Takeaways Renovation projects fail because of assumptions moreoften than calculations.Existing conditions should be verified—not inherited.Small undocumented field decisions can create majordownstream consequences.Shop drawings only work when they're actuallyfollowed.The cheapest question to ask is usually the one askedbefore construction begins.

    It Fit Yesterday
  5. 29 Jul ·  Bonus

    The Spec Trap: Install per Manufacturer's Instructions

    “Install per manufacturer’s instructions.” It’s one of the most common phrases in construction specifications—and one of the easiest ways to create expensive surprises. In this episode of The Spec Trap, Brian and Alex unpack what really hides behind that seemingly harmless sentence. From blocking that never made it onto the drawings to maintenance clearances, seismic bracing, structural supports,specialty anchors, and coordination conflicts, they explain why manufacturers’ installation requirements often contain critical design information that nobody discovers until the product has already been ordered. If you’ve ever opened a submittal and realized the installation manual contains more design requirements than the drawings… this one’s for you.  Leave feedback for Brian and Alex ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠brian@buildableish.com⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠   LINKS: Website:⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://buildableish.com/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Instagram:⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.instagram.com/buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ X:⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://x.com/Buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ LinkedIn:⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/company/buildable-ish/⁠⁠⁠ This episode is part of The Spec Trap series — short dives into spec language that sounds professional but quietly causes problems in the field.

    The Spec Trap: Install per Manufacturer's Instructions
  6. 22 Jul

    Panic Rooms and Parking Lots

    Security isn’t about making a building look intimidating—it’s about making people safer. When an owner says, “Make it more secure,” what does that actually mean? In this episode of Buildable{ish}, Brian welcomes physical security consultant Herb Ubbens to explore the difference between real security and what security professionals call security theater—design features that create the illusion of safety without actually reducing risk. From risk assessments and blast-resistant materials to ballistic glazing, bollards, active shooter mitigation, and hostile vehicle protection, they discuss why effective security starts long before construction documents are complete. They also explore how thoughtful planning, good architecture, and realistic threat assessments often provide better protection than simply adding thicker wallsand more steel. Whether you design healthcare facilities, government buildings, schools, or commercial spaces, this episode is a reminder that good security isn’t about making buildings look like fortresses—it’s about designing environments that quietly protect the people inside. Leave feedback for Brian and Alex ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠brian@buildableish.com⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠   LINKS: Website: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://buildableish.com/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Instagram: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.instagram.com/buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ X: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://x.com/Buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ LinkedIn: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/company/buildable-ish/⁠⁠⁠ Show Notes Chapter 1 – Security Theater vs. Real Security Why “make it safer” is one of the most dangerous design directives.The difference between perceived security and actual risk reduction.Why risk, threat, and vulnerability assessments should drive design decisions.Balancing occupant comfort with meaningful protection.Chapter 2 – Designing for Real Threats Blast resistance, ballistic glazing, and hostile vehiclemitigation.How bollards, barriers, and landscaping work together.Why every security feature should match a realistic threatassessment.Designing for resilience instead of reaction.Chapter 3 – The Illusion of Safety Why stronger doors don’t help if someone can simply goaround them.Common misconceptions about secure facilities.Balancing visibility, accessibility, and occupantconfidence.Why security is often about systems—not individual products. Chapter 4 – Lessons Learned Bring security specialists into the project early.Define realistic threats before selecting security measures.Integrate security with architecture instead of treating itas an afterthought.Remember that technology evolves—but sound design principles endure. Key Takeaways Security begins with understanding risk—not buying products.Early planning produces better security and lower project costs.Effective protection often comes from integrated designrather than heavier construction.Perceived safety and actual safety are not always the same thing.The best security measures are often the ones occupants never notice.

    Panic Rooms and Parking Lots
  7. 15 Jul ·  Bonus

    Redlines & Regrets: General Notes Roulette

    "It is in the general notes."  Six words that have launched countless RFIs, change orders, and construction arguments.  In this Redlines & Regrets minisode, Brian and Alex tackle one of the construction industry's oldest games: General Notes Roulette. They discuss why critical project requirements should never live only in dense blocks of boilerplate text, how hidden scope creates unnecessary disputes, and why important information isn't truly coordinated if nobody can find it.  From outdated boilerplate language and conflicting contract documents to invisible scope and expensive surprises, they explore why visibility—not just documentation—is the key to successful project coordination.  Leave feedback for Brian and Alex   ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠brian@buildableish.com⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠      LINKS:   Website: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://buildableish.com/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠  Instagram: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.instagram.com/buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠  X: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://x.com/Buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠  LinkedIn: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/company/buildable-ish/⁠⁠⁠  Show Notes: Signs you're playing General Notes Roulette:  Critical requirements exist only in the general notes.  Boilerplate notes haven't been updated for the current project.  Notes conflict with the drawings or specifications.  Scope changes are buried in dense text instead of shown on the plans.  Why it happens:  General notes become a safety net instead of good design.  Time pressure leads to last-minute note additions.  Drawings, specifications, and notes drift out of coordination.  Everyone assumes someone else read the general notes.  What happens in the field:  RFIs and change orders appear halfway through construction.  Contractors discover hidden scope after work has already started.  Responsibility turns into interpretation.  Relationships suffer while everyone argues over what was "reasonably inferable."  Takeaways:  If it matters, show it.  Boilerplate should be edited—not copied.  Coordinate your drawings, notes, and specifications.  Visibility creates accountability.  If it's important enough to enforce, it's important enough to draw.  Lesson Learned: If it's important enough to enforce, it's important enough to draw.    This episode is part of our Redlines & Regrets series—short stories from the field where small oversights become expensive lessons. Each episode explores real coordination failures, design decisions, and construction missteps so you don't have to learn them the hard way.

    Redlines & Regrets: General Notes Roulette
  8. 8 Jul

    Nailed the Estimate…Now Everyone Hates Me

    Every project starts with a budget, a concept, and someone asking, “How much could it cost?”  Then the estimator answers.  Brian is joined by veteran construction estimator John Carter to explore the uncomfortable reality of project estimating—where delivering accurate numbers can make you the least popular person in the room. From conceptual cost models and budget validation to subcontractor buyouts, bad bids, value engineering, and owners who ignore early warnings, this episode dives into why good estimating is far more than guessing a price. It’s forecasting risk, managing expectations, and sometimes saving a project from itself.  If you’ve ever watched a client fall in love with a design they couldn’t afford, wondered why identical buildings cost different amounts in different cities, or been blamed simply for delivering bad financial news…this one’s for you.  Leave feedbackfor Brian and Alex  ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠brian@buildableish.com⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠    LINKS: Website:⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://buildableish.com/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Instagram:⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.instagram.com/buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ X: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://x.com/Buildableish⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ LinkedIn:⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/company/buildable-ish/⁠⁠⁠ Show Notes  Chapter 1 – Budget? What Budget?  Why conceptual estimates are more art than science  Cost models, historical data, and the danger of outdated benchmarks  Why location, labor markets, and timing matter more than square-foot costs  Helping owners fall in love with projects they can actually afford  Why estimators should be part of the design conversation from Day One    Chapter 2 – Bid Day Reality  When subcontractor bids don’t match the estimate  Finding scope gaps before they become expensive mistakes  Reading between the lines of door schedules and electrical plans  Buyout logs, contingencies, and balancing the project budget  Building trust by helping subcontractors avoid costly errors    Chapter 3 – I Hate It When I’m Right  What happens when early budget warnings get ignored  Projects that become fully designed—but never get built  How inflation and code changes punish delayed decisions  Why estimators often become the scapegoat for uncomfortable truths  Solving problems instead of saying, “I told you so”    Chapter 4 – The Forgotten Post-Mortem  Why estimators rarely see the final project numbers  Learning from completed projects instead of assigning blame  Comparing estimated costs to actual project costs  Turning overruns into better estimating practices  Why every completed project should improve the next one    Key Takeaways  Estimating is about managing risk—not predicting the future.  The earlier cost realities are discussed, the more options everyone has.  Accurate estimates require experience, communication, and constant validation.  Bad news delivered early is almost always cheaper than bad news delivered late.  Being right about the budget doesn’t always make you popular—but it often saves the project.

    Nailed the Estimate…Now Everyone Hates Me

About

A smart, funny podcast cohosted by a structural engineer and a project manager – two professionals who live day-to-day in construction coordination. We take a candid, smart, and often humorous look at what really happens between design intent and finished construction. Each episode breaks down a common project challenge; misaligned specs, missing details, inspection surprises, field fixes, and the infamous “that wasn’t on the drawings” moment. Keywords: Buildable, Buildableish, Buildable ish, Build, Buildable(ish), Buildable (ish)