← Back to archive

Architectural debt starts outside the code

Just read a piece on architectural debt. It has nothing to do with technical debt, which is mostly code shortcuts.

The real problem starts outside the code.

There are a few layers:

  1. App / Infrastructure (easier to identify)
  • Not "rewrite that service in Rust", but why are we still moving files over sFTP and doing REST?
  • why do we pay for AWS storage & use SharePoint? your targets: vendor lock-in, overlaps, messy integrations - the points where delivery slows & bills go up.
  1. Business This is about ownership + reality

    Who handles a data leak? If you modernize one team and break five others - that’s debt definitely. You have bad docs/onboarding/process documentation. It equals to bad assumptions which in turn expensive mistakes.

  2. Strategy (highest impact) If your capability map is wrong, you’re building a 3–5 year plan on fiction. This is where transformations/ideas die before they even start.

Architects/CTO actually have (but usually don't have) the time + zoomed-out view to spot this stuff. Their job is basically: show people reality, show the mess, convince to fix it. And man ... that's sooooo hard sometimes.

Architectural debt starts outside the code

Originally posted on X

PS: I'm pretty active on 𝕏 if you'd like to follow along

Archive

2026

2025

2024

2018