Yes or No: most consulting firms and ProcureTech solution providers monetize dependency, not capability.

EDITOR’S NOTE: This “two-question” post was inspired by the following LinkedIn post by Miroslav Pitlanic.

QUESTION #1 – Is it possible to make shoe laces that never break, or a light bulb that never goes out? What things or products should be built to last but aren’t, and why?

Short answer: “never” is basically no. Entropy, wear, and chemistry win eventually. But you can design things to last far longer—if you accept trade-offs in cost, weight, efficiency, and style.

“Unbreakable” shoelaces?

• Why laces fail: abrasion against eyelets, knot compression/flex fatigue, UV and sweat chemistry, and aglets fraying first.
• How to make them almost unbreakable: use a double-braid with an abrasion-resistant sheath (e.g., UHMWPE/Dyneema or aramid/Kevlar blend) over a softer core; waxed or PU finish; molded or crimped metal aglets; smooth eyelets.
• Trade-offs: slick fibers make knots slip (need different weaves or textured sheath), harsher feel, higher price, and they’ll still eventually abrade. You move from months → many years, not “forever.”

“Light bulb that never goes out?”

• Incandescent: you can make them last decades by running the filament cooler—but brightness and efficiency crash (great life, dim light).
• LEDs: no filament to break, but lumen output decays (you rate life at L70—when it’s 70% as bright). With good heat sinking, gentle drive current, and robust drivers (avoid cheap electrolytic capacitors), 50k–100k+ hours is realistic. That’s 6–12+ years 24/7, but still not “never.”

Why many products aren’t built to last (even when they should be)

How to actually get longevity

• Design for repair: screws, not glue; standard fasteners; spare parts for 10+ years.
• Modularity: hot-swappable batteries/drivers; replaceable cables and aglets.
• Derate for life: run components below max stress (cooler LEDs, thicker bearings).
• Materials fit: abrasion-resistant sheaths (laces); higher-temp capacitors (electronics).
• Align incentives: warranties that scale with life; TCO-based procurement; right-to-repair.

Bottom line: You can’t beat physics, but you can choose where to spend—materials, thermal design, and repairability. That turns “breaks in a year” into “lasts a decade,” which is usually the smarter kind of “forever.”

QUESTION #2 – Referencing the LinkedIn post by Miroslav Pitlanic, how does it relate to the above answer:

This is the services-side version of Jim Collins’ “Built To Last.”
As previously stated, many products aren’t durable because incentives reward replacement, not longevity. Pitlantic’s post makes the same point for consulting: most firms monetize dependency, not capability. You’re flipping the incentive—automate, document, hand over—so the “product” (the client’s process) keeps working without you.

How it connects point-for-point

• Planned obsolescence vs. recurring billables
  Cheap hardware fails, so you have to buy it again; opaque consulting keeps you renewing. You’re rejecting both.
• Design for repair ≈ Design for client self-sufficiency
  Replaceable batteries/parts ↔︎ modular automations, clean code, docs, and admin training.
• Derate for life ≈ Don’t run processes at the ragged edge
  Cooler LEDs last longer ↔︎ sane SLAs, error budgets, and load-tested bots that don’t collapse at quarter-end.
• Right-to-repair ≈ Source transparency
  Standard fasteners ↔︎ open APIs, version-controlled scripts, no black-box macros, no hostage data.
• TCO over years ≈ Outcomes over hours
  Durable goods beat cheap upfronts ↔︎ measurable business KPIs beat billable time.

Why “automate yourself out of the job” works

• Trust increases when clients see you remove toil and transfer control.
• You trade low-value “transaction work” for higher-value transformation (advisory, architecture, road-mapping).
• It creates referenceable wins—just like durable products create loyal users.

If you want durability from vendors/consultants, hard-wire it into deals

• Outcome KPIs: cycle time and variance, error rate, adoption; pay on outcomes, not hours.
• Capability transfer: delivery isn’t “done” until in-house admins can run/modify automations.
• Transparency: require repo access, runbooks, environment-as-code, and API/DB schemas.
• Portability: data export scripts, no proprietary locks, exit/egress test before go-live.
• Reliability guardrails: change failure rate, MTTR, and evidenceable audit logs.
• Cost over time: show 3–5 year TCO vs. today’s manual cost; prefer designs that shrink OpEx.

Bottom line: Pitlanic’s post is the cultural mirror of product durability. Build capability, not dependence, and both machines and organizations last longer—and you get called for the next transformation, not the next ticket.

30