Show Description

“The survey covered it.”

Four words that can get very expensive once somebody starts digging.

In this Redlines & Regrets minisode, Brian and Alex dig into surveys, assumptions, and the dangerous gap between what a survey actually investigated and what everyone assumes it investigated. From utility survey quality levels and buried limitations to a geotechnical boring that found an eight-inch water main the hard way, they look at what happens when confidence replaces verification.

Because a completed survey does not mean a complete understanding of the site—and the ground doesn’t care what everyone assumed.

Listen here:

Apple Podcasts: https://podcasts.apple.com/us/podcast/buildable-ish/id1869438323

Spotify:https://open.spotify.com/show/2mrLDMHmM9RuuSFfWpwwVH?si=4c57b988b1174f1d

Show Notes

Signs you may be digging on an assumption:

• Everyone says “the survey covered it,” but nobody has read the scope.
• Missing information is treated as proof that nothing is there.
• Designers, contractors, and owners assume someone else verified the critical information.
• Survey limitations and exclusions never make it past the report.

Why it happens:

• Different surveys answer different questions.
• Budget, schedule, technology, and investigation methods limit what can actually be found.
• Survey scope gets lost as information moves between owner, consultant, designer, and contractor.
• Confidence grows each time the information changes hands—even when verification does not.

What happens in the field:

• A geotechnical boring finds an eight-inch water main that wasn’t shown.
• An excavator finds a buried gas line with a metallic “tunk” and a very loud whistle.
• Repairs, traffic control, delays, meetings, and finger-pointing replace the original project plan.
• Everyone finally reads the scope after the damage is done.

Takeaways:

• Define the survey scope around what the project actually needs.
• Read the report, not just the exhibit.
• Understand what was investigated—and what was not.
• Verify critical information before excavation, not during it.
• Design with the information you have, not the information you wish you had.

Lesson Learned: Don’t confuse a completed survey with a complete understanding of the site.

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.

Leave feedback for Brian and Alex

[email protected]

Follow us on

LinkedIn – Buildable{ish}

Instagram – Buildable{ish}

X – @Buildable{ish}

Show Description

It’s just an elevator project.

Until the elevator needs two more inches.

And those two inches are occupied by reinforced concrete.

Brian and Alex take on elevator modernization—the deceptively simple project type where a moving box inside a shaft somehow pulls structural, architectural, electrical, fire alarm, life safety, and project management into the samecoordination meeting.

From an elevator vendor asking for overhead clearance the existing building does not have to pits that need to get deeper, shafts that are nowhere near plumb, railsupports that do not line up with floor framing, and heavy machine-room equipment that still has to get through the building, they explore why elevator requirements can force the building to adapt around the equipment—not the otherway around.

They also dig into the scope gaps that appear once the vendor defines the real requirements: rail attachments, pit ladders, sump pits, fire alarm recall, feeders, shaft lighting, access, machine delivery paths, and the inevitable “by others” note that nobody wants to own.

Because the elevator vendor installs the elevator.

Everything around it still has to work.

If you’ve ever thought an elevator modernization was just replacing equipment inside an existing shaft…this episode is for you.

Website – ⁠⁠www.buildableish.com⁠⁠

Email – ⁠⁠[email protected]⁠⁠

LinkedIn – Buildable(ish)

Instagram – Buildable(ish)

X – @Buildableish

Show Notes

Elevators are one of the few building systems where the equipment does not simply adapt to the building. Once the vendor’s actual geometry, tolerances, loads, clearances, and support requirements arrive, the shaft either works—or thebuilding has to change around the elevator.

Chapter 1 – The Moving Box Dictates the Building

• Elevator projects that look simple in early design—until vendor requirements, existing conditions, and tolerances enter the conversation.
• Why existing shaft dimensions, pit depth, overhead clearance, plumbness, and squareness need to be field-verified before equipment procurement.
• Why rail loads, pit ladders, handrails, lighting, and other small requirements can become majorcoordination items.

Chapter 2 – When the Submittal Arrives

• What happens when the elevator shop drawings finally reveal the real rail-support spacing, loads, attachment points, and tolerances.
• Why rail-support spacing may not align with floor levels—and how intermediate spreader beams or supplemental structure become necessary.
• Fire alarm recall, life-safety interfaces, testing, and the coordination that suddenly pulls multiple disciplines into the elevator project.

Chapter 3 – Where Scope Gaps Go Vertical

• What the elevator vendor typically provides—and what remains the responsibility of the building and design teams.
• Planning how heavy elevator machinery actually gets from the loading dock to a machine room several floors away.
• Designing structural attachment points for elevator rails when the hoistway is shaft wall instead of masonry.

Chapter 4 – Lessons from the Machine Room

• Field-verify shaft dimensions, pit depth, overhead clearance, plumbness, and squareness before equipment is purchased.
• Plan equipment delivery and replacement routes as part of the design—not as a construction-day problem.
• Remember that a dimensional problem measured in inches can become a structural problem measured in weeks of redesign.

Key Takeaways

• Elevator modernization is a building-coordination project, not just an equipment replacement.
• The existing shaft should be measured and verified before procurement—not after the new equipment arrives.
• Pit depth, overhead clearance, shaft geometry, rail loads, and support locations can turn small dimensional differences into major structural work.
• Heavy elevator equipment still needs a realistic path through the building to the machine room, and that path may require structural review or temporary shoring.

It sounds responsible. It’s on renovation drawings everywhere. And sometimes…it means nobody actually checked.

In this Hold for Clarification minisode, Brian and Alex unpack “Verify in Field” and the difference between using field verification to manage uncertainty and using it to avoid doing the investigation. From a beam that existed four feet from where the drawings showed it to decades of renovations, buried conditions, scans, record drawings, and the surprises waiting behind walls, we dig into why “could not verify” and “did not verify” are not the same thing.

Show Notes

The phrase assumes:

·      Someone has already investigated what can reasonably be verified.

·      The drawings clearly identify what remains uncertain.

·      The contractor knows what must be confirmed before fabrication or installation.

In practice, it becomes:

·      A disclaimer attached to an assumption.

·      A decades-old dimension copied one more time.

·      A surprise waiting for demolition.

Takeaways:

·      Verify what can reasonably be verified during design.

·      Clearly distinguish “could not verify” from “did not verify.”

·      Use scans, record drawings, photos, and site investigation as tools—not proof.

·      If field verification affects fabrication or installation, say what must be verified and when.

“The drawings may show confidence. The building gets the final word.”

This episode is part of our Hold for Clarification series – short dives into the phrases that sound helpful, but create chaos in construction documents.

Leave feedback for Brian and Alex

[email protected]

Follow us on

Linked-in – Buildable{ish}

Instagram – Buildable{ish}

X - @Buildable{ish}

Episode 014 – Designing Around a Ghost Vendor

Show Description

The drawings need exact dimensions.

The vendor won’t give them to you.

And the project still has to go out.

Brian and Alex are joined by returning guest Emilie Diggs to talk about what happens when a design team has to coordinate highly specific equipment before theequipment—or sometimes even the vendor—has actually been selected.

Using a surgical renovation as the backdrop, they dig into the uncomfortable gap between procurement and physical reality. Surgical booms, C-arms, integrated manifold systems, ceiling heights, structural supports, clearances, vibration criteria, power, cooling, and shielding all require real information. But when procurement rules keep the vendor at arm’s length, the design team is left trying to turn assumptions into construction documents.

From a surgical boom that drifted into a patient because its center of gravity changed to an MRI that briefly matched the resonant frequency of the floor, they explore what happens when the equipment that eventually arrives isn’t quite the equipment everyone designed around.

Because procurement can tolerate ambiguity.

Physics cannot.

If you’ve ever designed around a basis of design that was unofficial, hypothetical, or mostly based on hope and a PDF…this episode is for you.

Links & Contact

Website – ⁠⁠www.buildableish.com⁠⁠

Email – ⁠⁠[email protected]⁠⁠

LinkedIn – Buildable(ish)

Instagram – Buildable(ish)

X – @Buildableish

Show Notes

Chapter 1 – The Basis of Design Without a Basis

• Why equipment procurement and design schedules rarely line up perfectly.
• What a basis of design is supposed to provide—and what happens when it can’t be confirmed.
• Designing surgical spaces around equipment dimensions, clearances, mounting requirements, shielding, power, cooling, and air-change requirements.
• Why reference sheets and approximate dimensions aren’t enough when tolerances are measured in fractions of an inch.
• How changing vendors—or even changing surgeons—can change the equipment requirements.
• Why rapidly changing medical technology makes early equipment decisions even more complicated.

Chapter 2 – Physics Doesn’t Care About Procurement

• The surgical boom that drifted into a patient after an equipment attachment changed its center of gravity.
• Why equipment weight is only part of the structural problem.
• Boom reach, eccentric loads, deflection, vibration, and mounting geometry.
• The MRI that briefly matched the resonant frequency of the floor during startup and shutdown.
• Why seemingly minor differences between equipment models can affect structural supports, ceilings, lighting, manifolds, clearances, and entire rooms.
• What happens when the real equipment finally arrives and the assumptions don’t match.

Chapter 3 – When Neutrality Meets Buildability

• Why an owner may have legitimate reasons for delaying equipment selection.
• Balancing procurement fairness, funding, technology changes, and the risk of appearing to favor a particular vendor.
• How procurement ambiguity migrates into scope, schedule, budget, coordination, and construction.
• Why vendor drawings need to be reviewed carefully for warnings, exclusions, “by others” notes, and responsibilities pushed back onto the design team.
• Using equipment envelopes, performance criteria, and clearly documented assumptions when exact information isn’t available.

Chapter 4 – Designing for the Unknown

• Designing to a credible worst-case condition when the final equipment is unknown.
• Creating adaptable support zones instead of relying on a single assumed mounting point.
• Putting critical assumptions where contractors can actually see them.
• Making future coordination a defined process instead of simply saying “coordinate later.”
• Identifying who owns each assumption and when it must be validated.

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

[email protected]⁠⁠⁠

Links

• Website – ⁠⁠www.buildableish.com⁠⁠
• LinkedIn – Buildable(ish)
• Instagram – Buildable(ish)
• X – @Buildableish

Show 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.

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 – ⁠[email protected]⁠
• 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.

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

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠[email protected]⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

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 Alex
[email protected]

Follow us on
LinkedIn – Buildable{ish}
Instagram – Buildable{ish}
X – @Buildable{ish}

"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

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠[email protected]⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

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.

“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

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠[email protected]⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

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.

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

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠[email protected]⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

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.